Onion Architektur Abhängigkeiten in der gleichen Schicht: Infrastruktur und Web-Kommunikation

Question

Ich entwerfe eine ASP.NET MVC-Anwendung mit der Onion Architecture von Jeffrey Palermo beschrieben.

Es ist ein ASP.NET MVC 2.0-Projekt, wo ich alle Ansichten stark mit dedizierten Ansichtsmodellen typisiert werden müssen - wir werden keine Domänenmodelle an unsere Ansichten übergeben. Wir verwenden AutoMapper für die Übersetzung - AutoMapper ist in der Infrastruktur isoliert, das Web weiß nicht, ob AutoMapper verwendet wird oder nicht.

Derzeit definiere ich die IViewModelMapping-Schnittstellen im Webprojekt - einfach weil dieser Dienst von den Controllern verwendet wird und er direkten Zugriff auf seine eigenen Ansichtsmodelle hat. Auf diese Weise kann die Schnittstelle sowohl auf die Domänenmodelle (im Kern) als auch auf die Ansichtsmodelle (im Web) zugreifen.

Um die tatsächliche Implementierung der IViewModelMapping-Schnittstellen bereitzustellen, habe ich im Infrastructure-Projekt einen ObjectMapping-Namespace erstellt, der die tatsächliche Mapping-Implementierung auf die Intrastruktur des Onion isoliert. Dies setzt voraus, dass die Infrastruktur von BEIDE Core AND Web abhängig ist.

Meine Frage ist: Da beide Projekte technisch am Rande der Zwiebel (in der gleichen Schicht) sind - darf ein Projekt eine Abhängigkeit von einem anderen Projekt in dieser Schicht haben? Wer bemerkt irgendwelche möglichen Fallstricke mit diesem Entwurf?

Ein alternativer Entwurf wäre das Verschieben der IViewMapper-Schnittstellen in Core - aber das wäre unmöglich, da Core keinen Zugriff auf die ViewModel-Klassen hat. Ich könnte die Ansichtsmodelle auch in Core verschieben, aber ich glaube, sie würden nicht dorthin gehören, da sie spezifisch für die UI-Ebene sind.

Die vorgeschlagene Architektur ist wie folgt - beachten Sie, dass Infrastruktur eine Abhängigkeit von Core AND Web hat. Das Web bleibt isoliert und hat nur Zugriff auf die Kerngeschäftslogik.

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

Answer 1

Sie sind richtig, dass Sie nicht Infrastructure auf UI (Web) abhängen wollen, aber ich brechen manchmal die Regel.

Ich würde statt IViewModelMapping denken, erstellen Sie IMapper mit der Methode Map(). Dann kann die Schnittstelle Implementierungen haben, die möglicherweise mit der Ansichtsmodellzuordnung oder vielleicht nur mit der regulären Zuordnung zu tun haben. In jedem Fall kann sich diese Schnittstelle in Core befinden, da sie nicht semantisch an einen beliebigen Modelltyp gebunden ist.

Großartige Grafik. Ich hoffe, ich habe das Fleisch deiner Frage beantwortet. Die allgemeine Philosophie der Onion-Architektur besteht darin, Ihre Geschäftslogik und Ihr Geschäftsmodell in der Mitte (Kern) Ihrer Anwendung zu halten und Ihre Abhängigkeiten so weit wie möglich nach außen zu lenken.

Answer 2

Versuchen Sie, Objekt Mapping in Web Schicht zu verschieben.

Answer 3

Ihre Web-/Benutzeroberflächenebene kann von der Infrastrukturschicht abhängig sein. Es ist jedoch kein gutes Design, eine Abhängigkeit von der Ebene "Web auf Infrastruktur" zu haben. Zwiebel Architektur sagt, schieben Sie Ihre Abhängigkeiten so weit wie möglich nach außen.

Sie können einen Ordner "\ Builder" in UI erstellen. Fügen Sie eine Interface-Datei hinzu, zB .. IBuilder oder IMapper und deklarieren Sie eine Methode wie ConvertToViewModel oder CreateMapping darin. was immer du magst.

* Builder ** IBuilder.cs -declare eine Methode hier. ** Builder.cs - - Implementieren Sie die Methode hier, definieren Sie die Zuordnung zwischen einem ViewModel und dem entsprechenden DomainModel (Referenz von der Core-Ebene) und geben Sie das entsprechende ViewModel hier zurück.