Pytanie Czy kontroler w MVC rozważa usługę aplikacji dla DDD?


Używam DDD dla części M mojego MVC i po kilku badaniach (studiowaniu!), Doszedłem do wniosku, że potrzebuję mojego kontrolera do interakcji z usługami domeny (w modelu). To spowodowałoby, że mój kontroler stałby się konsumentem usług domenowych, a tym samym usługi aplikacji (w kategoriach DDD). Czy to jest dokładne? Czy istnieje różnica między kontrolerem a tym, co DD definiuje jako usługa aplikacji?


11
2017-09-05 15:32


pochodzenie




Odpowiedzi:


Kontroler nie jest uważany za usługę w DDD. Kontrolery działają w warstwie interfejsu użytkownika. Usługi aplikacji pobierają dane z DB, sprawdzają poprawność danych, przekazują dane do klienta (MVC może być klientem, ale może również żądanie pochodzi z aplikacji WinForm) itp.

Cały kontroler wykonuje obsługę żądań z interfejsu użytkownika. Nie jest częścią domeny aplikacji.


7
2017-09-05 17:00



Usługa kontrolera żąda od widoku, przekazując wniosek - lub stosowną jego część - do Modelu. MVC jest architekturą i z pewnością można ją zastosować do winformów i aplikacji internetowych. Błagam o różnice dotyczące pozycji kontrolera. Widok jest zdecydowanie jedyną warstwą UI, a punktem MVC jest utrzymywanie tej warstwy UI oddzielnie od kontrolera. Twoja uwaga jest dobrze przyjęta; Dzięki za odpowiedzi. - Louis
-1. Kontrolery są koordynatorami wniosków / poleceń. W architekturze heksagonalnej architektury znajdują się tuż nad usługami aplikacji / programami obsługi komend / procedurami obsługi zapytań. Kontrolery są tłumaczami żądań i są połączone z protokołem komunikacyjnym (górna warstwa) i obsługą poleceń / zapytań (usługi aplikacji z niższego poziomu). Kontrolery mogą być postrzegane jako fasady usług aplikacji, ponieważ tłumaczą i przygotowują polecenie / zapytanie / wiadomość do przetwarzania przez warstwy niższego poziomu (usługi aplikacji / komendy zapytań). - Tudor
-1 ponieważ kontrolery nie mają nic wspólnego z DDD. Nie ma znaczenia, gdzie umieścić kontrolerów, można powiedzieć, że kontrolerzy są jedynie koordynatorami komunikacji / komunikacji i są połączeni w obie strony: ui i usługa aplikacji. Możesz mieć kontrolerów w ograniczonym kontekście, w którym nie ma interfejsu użytkownika (czysty kontekst dowodzenia). I możesz mieć ograniczony kontekst tylko do prezentacji (złożony komponent biznesowy stworzony tylko do sprawdzania 2 lub więcej ograniczonych kontekstów). P.S. kontrolery mają niskie sprzężenie z interfejsem użytkownika, oczekują jedynie zestawu parametrów żądania niezależnie od miejsca. - Tudor


Architektura warstwowa dzieli aplikację na warstwy UI, warstwy aplikacji, warstwy domeny i warstwy infrastruktury (Vaugn Vernons implementujący projekt oparty na domenie (lokalizacja 2901)). Kontroler jest objęty "Warstwą aplikacji" tej szerszej architektury projektowej, a zatem wchodzi w interakcje bezpośrednio z usługami domeny w modelu i jest uważany za usługę aplikacji. Co więcej, oczywiście wykorzysta również dostępne encje i agregaty.


1
2017-09-07 13:20



Jeśli spojrzysz na pg. 72 DDD firmy Evan zobaczysz, że rysunek 4.1 pokazuje kontroler będący częścią warstwy interfejsu użytkownika. Ma to sens, ponieważ jeśli V i C będą na osobnych warstwach, będziecie mieli intymne połączenie między nimi, gdy warstwy będą połączone tylko przez pośrednie i interfejsy. - Gordon
@Louis, nie czytałem książki Vaugona Vernonsa, ale właśnie udało mi się ukończyć udany projekt DDD. Wszystko, co mogę powiedzieć, to to, że kontrolerzy byli w całkowicie oddzielnym projekcie, projekcie klienta. Klient w naszym przypadku był front-endem MVC. To mógł być każdy inny klient. Warstwa Aplikacji była całkowicie odrębnym projektem, który stanął na własnych nogach. Miał swoje własne walidatory i mógł dostarczać dane za pośrednictwem interfejsu WCF. Kontrolery w kliencie MVC jedynie nazywały metody proxy warstwy aplikacji. Poza tym nie pełniły żadnej innej funkcji. - Greg
@ Gordona V i C można oddzielić za pomocą widoków pasywnych lub kontrolerów nadzoru. W przypadku niektórych aplikacji ich łączenie niekoniecznie jest złym pomysłem. To zależy w dużej mierze od specyfiki opracowywanej aplikacji. W świetle twojego odniesienia do strony 72 Evansa, wycofam moją odpowiedź, ponieważ wydaje się, że istnieją inne podejścia, które różnią się od moich. Dzięki za odpowiedzi. Chciałbym móc przeprowadzić dobrą dyskusję na temat SO bez ryzyka, że ​​pytanie zostanie zamknięte, ponieważ nie jest konstruktywne;) - Louis
@Greg, Z pewnością możesz mieć pełną aplikację MVC jako klient. Tak się dzieje, gdy używasz dobrze zaprojektowanej aplikacji w postaci biblioteki DLL. MVC izoluje funkcję zapewnianą przez ten fragment kodu. Moje pytanie ma na celu zbadanie niższej warstwy rozwoju. Jeśli używasz DDD jako części otaczającej architektury MVC, kontroler będzie służył jako warstwa aplikacji. Jeśli utworzysz oddzielną warstwę aplikacji, zduplikujesz wiele, jeśli nie wszystkie, kodu w kontrolerze. W przypadku walidatorów: Jeśli zatwierdzasz dane wejściowe, użyj kontrolera. Jeśli dane, użyj encji. - Louis
@Louis - tak, wkrótce to się skończy. Jak już powiedziałeś, mieliśmy mnóstwo zduplikowanych kodów, ale tego właśnie można się spodziewać, budując poziomy, które są całkowicie niezależne od siebie. Wszelkie udostępnianie kodu tworzy zależności. Nie mogliśmy używać kontrolerów do sprawdzania poprawności, ponieważ aplikacja mogła potencjalnie obsługiwać klientów, którzy napisali własne interfejsy do systemu, więc w takim przypadku nie mielibyśmy kontroli nad sprawdzaniem poprawności strony klienta. Dlatego weryfikacja musi zostać powtórzona w warstwie aplikacji. - Greg


Warstwa aplikacji znajduje się gdzieś pomiędzy warstwą domeny a warstwą prezentacji. Kontroler jest częścią warstwy prezentacji, wysyła polecenia lub zapytania do warstwy aplikacji, gdzie usługi aplikacji wykonują je przy użyciu usług i obiektów modelu domeny. Tak więc kontrolery różnią się od usług aplikacji i są prawdopodobnie związane z rzeczywistą formą komunikacji, np. HTTP. Nie powinieneś bezpośrednio wywoływać usług domenowych od kontrolerów, może to być oznaką niewłaściwie umieszczonego kodu.

Domain Driven Design: Domain Service, Application Service

  • Usługi domenowe: ujmuje logikę biznesową, która w naturalny sposób nie pasuje do obiektu domeny i NIE jest typową operacją CRUD -   te należałyby do repozytorium.
  • Usługi aplikacji: używane przez zewnętrznych klientów do rozmowy z twoim systemem (pomyśl o usługach internetowych). Jeśli konsumenci potrzebują dostępu do CRUD   operacje, zostaną ujawnione tutaj.

Więc twoja usługa to prawdopodobnie usługa aplikacji, a nie usługa domeny lub niektóre usługi aplikacji częściowej, niektóre usługi części domeny. Powinieneś sprawdzić i poprawić kod. Myślę, że po 4 latach to nie ma znaczenia, ale miałem takie same myśli przez aplikację, którą obecnie rozwijam. Ta aplikacja może być zbyt mała, aby można było na niej użyć DDD, więc mylące kontrolerzy z usługami aplikacji są oznaką nadmiernego przeciągania.

To ciekawe pytanie, kiedy zacząć dodawać kolejne warstwy. Myślę, że każda aplikacja powinna zacząć od jakiegoś rodzaju model domeny i adaptery połączyć się z tym modelem domeny. Więc jeśli aplikacja jest wystarczająco prosta, dodanie więcej niż 2 warstw może nie być konieczne. Ale to tylko myśl, nie mam takiego doświadczenia z DDD.


1
2018-02-09 02:18