Opinia w sprawie ASP.NET MVC Onion-based architecture [zamknięta]

Wprowadzam swoje usługi do moich kontrolerów. Usługi zwracają DTO, które znajdują się w Core. Model, który masz wygląda dobrze, nie używam wzorca repozytorium, ale wiele osób tak. Trudno mi pracować z EF w tego typu architekturze, dlatego zdecydowałem się na użycie Nhibernate.

Możliwa odpowiedź na twoje ostatnie pytanie.

1. Rdzeń
2. domena
3. DI
4. Infrastruktura
5. prezentacja
6. usługi

Moim zdaniem:

• " w klasycznej architekturze cebulowej rdzeń odnosi się tylko do następnej warstwy." Nie jest to prawdą, rdzeń powinien być odwołany przez dowolną warstwę... pamiętaj, że kierunek zależności między warstwami jest w kierunku centrum (rdzenia).

"warstwy powyżej mogą używać dowolnej warstwy pod nimi" Jeffrey Palermo http://jeffreypalermo.com/blog/the-onion-architecture-part-3/

Jeśli chodzi o Twój EF, to jest w złym miejscu.... Informatyka powinien znajdować się w warstwie infrastruktury, a nie w warstwie rdzenia. I użyj poco Generator do tworzenia encji (klas POCO) w Core/Model. Można też użyć Auto-mapera, aby zmapować Model Podstawowy (obiekty biznesowe) do modelu encji (encje EF)

To, co zrobiłeś, wygląda całkiem nieźle i jest w zasadzie jedną z dwóch standardowych architektur, które często widzę.

Mieszane uczucia o:

Dobrze, mamy implementację repozytorium pluggable, ale jak często naprawdę masz różne implementacje tego samego interfejsu persistence?

Pluggable jest często reklamowany jako dobry projekt, ale nigdy nie widziałem, aby zespół zamienił poważną implementację czegoś na coś innego. Tylko modyfikują istniejące rzecz. IMHO "pluggability" jest przydatny tylko dla możliwości makietowania komponentów do automatycznego testowania jednostek.

Nie jestem pewien, czy interfejs użytkownika powinien komunikować się tylko z warstwą biznesową za pomocą modeli widoku, czy też powinienem używać modeli domeny do przesyłania danych, tak jak teraz. Do wyświetlania używam modeli widoku, ale do przesyłania danych używam modeli domeny. Źle?

Myślę, że modele widoku są problemem UI (MVC Web), jeśli dodasz inny typ interfejsu, na przykład może nie wymagać wyświetl Modele lub może potrzebować czegoś innego. Myślę więc, że warstwa biznesowa powinna zwracać encje domeny i pozwalać na mapowanie ich w celu wyświetlania modeli w warstwie interfejsu użytkownika.

Czego nie lubię:

Core project jest teraz odwoływany w każdym innym projekcie - ponieważ Chcę / muszę uzyskać dostęp do Modeli domeny. W klasycznej architekturze cebulowej do rdzenia odwołuje się tylko następna warstwa.

Jak mówili inni, jest to całkiem normalne. Zazwyczaj wszystko kończy się na zależność od domeny.

DbContext jest zaimplementowany wCore project, ponieważ jest generowany przez ramy Entity, w tym samym miejscu, w którym.edmx jest. Chcę skorzystać z ... EDMX dla projektu modelu wizualnego, ale czuję, że DbContext należy do warstwy Persistence, gdzieś w implementacji repozytorium specyficznej dla bazy danych.

Myślę, że jest to konsekwencja struktury podmiotu. Jeśli użyłeś go w trybie "Code First", możesz - i zazwyczaj-mieć kontekst i repozytorium w warstwie Persistance z domeną (reprezentowaną jako klasy POCO) w tym, co nazwałeś rdzeniem.

Jako ostatnie pytanie-co to jest dobra architektura, która nie jest przerobiona (np. pełnowymiarowa cebula, gdzie mamy zastrzyki, lokalizatory usług itp.), ale jednocześnie zapewnia pewną rozsądną elastyczność, w miejscach, w których realnie jej potrzebujesz?

Jako że poruszyłem wyżej nie martwiłbym się o potrzeba wymiany rzeczy z wyjątkiem umożliwienia zautomatyzowanych testów jednostkowych. Chyba że istnieje konkretny wymóg, o którym wiesz, że to bardzo prawdopodobne.

Powodzenia!