Dipendenze di archicecture di onion nello stesso livello: infrastruttura e comunicazione Web

Question

Sto progettando un'applicazione ASP.NET MVC utilizzando lo Onion Architecture descritto da Jeffrey Palermo.

Si tratta di un progetto ASP.NET MVC 2.0, in cui è necessario che tutte le viste vengano digitate con i modelli di vista dedicati - non passeremo i modelli di dominio alle nostre visualizzazioni. Stiamo utilizzando AutoMapper per eseguire la traduzione: AutoMapper è isolato nell'infrastruttura, Web non sa o cura che AutoMapper sia in uso.

Attualmente sto definendo le interfacce IViewModelMapping nel progetto Web, semplicemente perché questo servizio verrà utilizzato dai controller e ha accesso diretto ai propri modelli di visualizzazione. In questo modo l'interfaccia può accedere sia ai modelli di dominio (in Core) che ai modelli di visualizzazione (in Web).

Al fine di fornire l'effettiva implementazione delle interfacce IViewModelMapping, ho creato uno spazio dei nomi ObjectMapping nel progetto Infrastructure, che isolerà l'effettiva implementazione della mappatura nell'Intrastruttura della cipolla. In tal modo, ciò richiederà che Infrastructure abbia una dipendenza da BOTH Core AND Web.

La mia domanda è: poiché entrambi questi progetti sono tecnicamente alla periferia della cipolla (nello stesso livello) - un progetto può avere una dipendenza da un altro progetto in quel livello? Qualcuno nota qualche potenziale insidia con questo design?

Un progetto alternativo sposterebbe le interfacce IViewMapper in Core, ma ciò sarebbe impossibile perché Core non ha accesso alle classi ViewModel. Potrei anche spostare i modelli di visualizzazione in Core, ma mi sento come se non appartenessero a loro, poiché sono specifici per il livello dell'interfaccia utente.

L'architettura proposta è la seguente: si noti che Infrastructure ha una dipendenza da Core AND Web. Il Web rimane isolato e ha solo accesso alla logica aziendale principale.

http://www.matthidinger.com/images/onion-arch.png

Answer 1

Lei ha ragione che non si vuole Infrastructure dipendere da UI (web), ma mi rompere questa regola a volte.

Penso che invece di IViewModelMapping, crei IMapper con metodo Map(). Quindi, l'interfaccia può avere implementazioni che potrebbero avere a che fare con la mappatura del modello di vista, o forse solo una mappatura regolare. In entrambi i casi, che l'interfaccia può essere in Nucleo perché non è semanticamente legato a qualsiasi tipo di modello.

Grande grafica. Spero di aver risposto alla carne della tua domanda. La filosofia generale della cipolla Architettura è quello di mantenere la logica di business e il modello in mezzo (Core) della vostra applicazione e spingere le dipendenze, per quanto verso l'esterno il più possibile.

Answer 2

Prova a spostare Mappatura oggetto in Livello Web.

Answer 3

vostro strato/UI Web può essere dipendente livello di infrastruttura. Ma non è un buon progetto avere dipendenza dal livello Web su infrastruttura. L'architettura di Onion dice che spingete le vostre dipendenze il più lontano possibile.

È possibile creare una cartella "\ Builder" nell'interfaccia utente. Aggiungi un file di interfaccia al suo interno, ad esempio .. IBuilder o IMapper e dichiara un metodo come ConvertToViewModel o CreateMapping in esso. qualunque cosa ti piaccia

* Builder IBuilder.cs ** dichiarare queste ultime un metodo qui. ** Builder.cs - - Implementa il metodo qui, definisce il mapping tra un ViewModel e il corrispondente DomainModel (riferimento dal livello principale) e restituisce ViewModel appropriato qui.