Zależności między architekturą jądrową w tej samej warstwie: infrastruktura i komunikacja sieciowa

Question

Projektuję aplikację ASP.NET MVC przy użyciu modelu Onion Architecture opisanego przez Jeffrey'a Palermo.

Jest to projekt ASP.NET MVC 2.0, w którym wymagam, aby wszystkie widoki były silnie wpisywane za pomocą dedykowanych modeli widoku - nie będziemy przekazywać modeli domen do naszych widoków. Używamy AutoMappera do tłumaczenia - AutoMapper jest izolowany w infrastrukturze, Web nie wie ani nie obchodzi, że jest używana AutoMapper.

Obecnie definiuję interfejsy IViewModelMapping w projekcie WWW - po prostu dlatego, że ta usługa będzie używana przez Kontrolery i ma bezpośredni dostęp do własnych modeli widoku. W ten sposób interfejs może uzyskać dostęp zarówno do modeli domen (w rdzeniu), jak i modeli widoków (w sieci).

W celu zapewnienia rzeczywistej implementacji interfejsów IViewModelMapping utworzyłem obszar nazw ObjectMapping w projekcie Infrastruktura, który wyizoluje rzeczywistą implementację mapowania do Intrastruktury cebuli. Czyniąc to, będzie wymagać, aby infrastruktura była zależna od OBU Core and Web.

Moje pytanie brzmi: ponieważ oba te projekty są technicznie na obrzeżach cebuli (w tej samej warstwie) - czy jeden projekt może mieć zależność od innego projektu w tej warstwie? Czy ktoś zauważy potencjalne pułapki z tym projektem?

Alternatywnym projektem byłoby przenoszenie interfejsów IViewMapper do Core - ale byłoby to niemożliwe, ponieważ Core nie ma dostępu do klas ViewModel. Mogłabym też przenieść modele widoku do Core, ale czuję, że nie pasują do nich, ponieważ są specyficzne dla warstwy interfejsu użytkownika.

Zaproponowana architektura wygląda następująco - należy zauważyć, że infrastruktura jest zależna od Core AND Web. Sieć pozostaje odizolowana i ma dostęp tylko do podstawowej logiki biznesowej.

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

Answer 1

Masz rację, że nie chcesz Infrastruktura polegać na interfejsie (WWW), ale czasami złamać tę regułę.

Zastanowiłbym się zamiast IViewModelMapping, utwórz IMappera za pomocą metody Map(). Następnie interfejs może mieć implementacje, które mogą mieć związek z mapowaniem modelu widoku, a może zwykłym mapowaniem. Tak czy inaczej, ten interfejs może być w rdzeniu, ponieważ nie jest semantycznie związany z żadnym typem modelu.

Świetna grafika. Mam nadzieję, że odpowiedziałem na mięso twojego pytania. Ogólną filozofią architektury cebuli jest utrzymanie logiki biznesowej i modelu w środku (Core) aplikacji i wypychanie zależności tak daleko, jak to możliwe.

Answer 2

Spróbuj przenieść Object Mapowanie na warstwę Web.

Answer 3

Twoja warstwa Web/UI może być zależna od warstwy Infrastruktury. Ale to nie jest dobry projekt, aby mieć zależność od sieci na warstwie infrastruktury. Architektura cebuli mówi, aby twoje zależności były jak najbardziej oddalone.

Możesz utworzyć folder "\ Builder" w interfejsie użytkownika. Dodaj do tego jeden plik interfejsu, przykład .. IBuilder lub IMapper i zadeklaruj w nim metodę taką jak ConvertToViewModel lub CreateMapping. cokolwiek lubisz.

* Konstruktor ** IBuilder.cs - należy tu podać metodę. ** Builder.cs - - Zaimplementuj tutaj metodę, zdefiniuj mapowanie między ViewModel i jego odpowiednikiem DomainModel (odniesienie z warstwy rdzenia) i zwróć odpowiedni ViewModel tutaj.