Iniettore semplice nell'architettura a strati di cipolla

0

Sto cercando di trovare una buona risorsa, un consiglio, ecc. in un progetto che mi sono preso al lavoro.

Sfondo

Quando ho iniziato qui avevamo un'applicazione che faceva parte di Webform parte MVC (progetti separati su una soluzione) strettamente accoppiata al suo DAL con codice aziendale dappertutto.

Ho rifattorato l'intera soluzione nell'architettura a strati di cipolla quasi due anni fa usando ninject. ha ucciso i suoi servizi SOAP in favore di WebAPI e ha spostato la stragrande maggioranza dei Webforms in straordinari MVC. (ne rimangono ancora in Webform, ma i loro giorni sono numerati)

Nel complesso, questo è stato un grande successo per quanto riguarda la manutenibilità, la stabilità e la logica aziendale in cui appartiene. Ultimamente la performance è stata un problema crescente. Abbiamo stabilito molteplici cause, ma siamo rimasti sorpresi dal fatto che le nostre prestazioni hanno influito negativamente sulle nostre prestazioni, dopo alcune ricerche abbiamo scoperto che uno dei peggiori framework DI dal punto di vista delle prestazioni era quello di ninject. Con questo in mente ci stiamo muovendo verso un semplice iniettore che ci ha impressionato.

Il problema

Non limitiamo solo a riscrivere il nostro lavoro, lo spostiamo gradualmente laddove possibile. Sappiamo tutti che non siamo in grado di combinare realisticamente le cose con il semplice e non aspettarci un caos totale. Con questo in mente abbiamo ripulito il nostro codice per assicurarci che tutto funzionasse con entrambi i componenti, sia semplici che semplici, e siamo alla fase finale del cablaggio completo di tutto ...

Ad eccezione di tutte le guide, tutorial e esempi che ho trovato, l'effettivo progetto dell'interfaccia utente (MVC) fa riferimento sia all'interfaccia che al progetto in cui inserirò le mie lezioni da ...

Esempio:

container.Register<ILoggingService, LoggingService>();

Con Onion Architecture abbiamo cercato di assicurarci che il nostro front-end non avesse riferimenti diretti al codice di supporto. Questo è stato gestito avendo un progetto separato dal mio progetto MVC per gestire l'iniezione, permettendomi così di non avere mai un riferimento tra la mia interfaccia utente e il mio codice back-end. (Così impedendoti di bypassare accidentalmente la tua interfaccia e DI)

Quanto sopra mi richiederebbe di fare direttamente riferimento al codice back-end e, a mio parere, fondamentalmente sconfiggere ciò che abbiamo cercato di fare. Forse le mie teste non sono tutte insieme stanche + mentalmente in vacanza, ma sto provando un bel po 'di tempo a cercare di capire come realizzare ciò che avevamo sotto novizio in un semplice iniettore (sono sicuro che sia stupido facile, ma Ho battuto la testa su questo per ore quindi qualsiasi aiuto sarebbe andato lontano)

    
posta RualStorge 26.11.2014 - 21:53
fonte

1 risposta

1

Di solito, c'è un qualche tipo di progetto "Application" o "Launcher", che fa riferimento ad ogni assembly che l'applicazione deve eseguire. Solo la responsabilità di questo progetto è di collegare le dipendenze e avviare l'applicazione. Non ha interfaccia utente e nessun comportamento. Ma non sono sicuro di come verrebbe gestito nell'applicazione MVC.

    
risposta data 27.11.2014 - 08:27
fonte

Leggi altre domande sui tag