Czy usługi powinny zawsze zwracać DTO, czy też mogą zwracać modele domen?


174

Projektuję (re) dużą aplikację, używamy architektury wielowarstwowej opartej na DDD.

Mamy MVC z warstwą danych (implementacja repozytoriów), warstwą domenową (definicja modelu domeny i interfejsów - repozytoria, usługi, jednostka pracy), warstwą usługową (implementacja usług). Do tej pory używamy modeli domenowych (głównie encji) na wszystkich warstwach, a DTO używamy tylko jako modeli widoku (w kontrolerze usługa zwraca model (y) domeny, a kontroler tworzy model widoku, który jest przekazywany do widoku).

Czytałem niezliczone artykuły o używaniu, nieużywaniu, mapowaniu i przekazywaniu DTO. Rozumiem, że nie ma żadnej ostatecznej odpowiedzi, ale nie jestem pewien, czy jest to w porządku, czy nie zwracam modeli domeny z usług do kontrolerów. Jeśli zwracam model domeny, nadal nie jest on przekazywany do widoku, ponieważ kontroler zawsze tworzy model widoku specyficzny dla widoku - w tym przypadku wydaje się to uzasadnione. Z drugiej strony nie wydaje się dobrze, gdy model domeny opuszcza warstwę biznesową (warstwę usług). Czasami usługa musi zwrócić obiekt danych, który nie został zdefiniowany w domenie, a następnie albo musimy dodać nowy obiekt do domeny, która nie jest mapowana, albo utworzyć obiekt POCO (jest to brzydkie, ponieważ niektóre usługi zwracają modele domeny, niektóre skutecznie zwrócić DTO).

Pytanie brzmi - jeśli ściśle używamy modeli widoku, czy można zwracać modele domeny aż do kontrolerów, czy też powinniśmy zawsze używać DTO do komunikacji z warstwą usług? Jeśli tak, czy można dostosować modele domen w oparciu o potrzebne usługi? (Szczerze mówiąc, nie sądzę, ponieważ usługi powinny zużywać to, co ma domena.) Jeśli powinniśmy ściśle trzymać się DTO, czy powinny być zdefiniowane w warstwie usług? (Myślę, że tak.) Czasami jest jasne, że powinniśmy używać DTO (np. Gdy usługa wykonuje dużo logiki biznesowej i tworzy nowe obiekty), czasami jest jasne, że powinniśmy używać tylko modeli domeny (np. Gdy usługa członkostwa zwraca anemiczny użytkownik ( s) - wydaje się, że nie miałoby sensu tworzenie DTO, które jest takie samo jak model domeny) - ale wolę spójność i dobre praktyki.

Artykuł Domena vs DTO vs ViewModel - jak i kiedy ich używać? (a także kilka innych artykułów) jest bardzo podobny do mojego problemu, ale nie zawiera odpowiedzi na to pytanie (a). Artykuł Czy za pomocą EF należy implementować DTO we wzorcu repozytorium? jest również podobny, ale nie dotyczy DDD.

Zastrzeżenie: nie zamierzam używać żadnego wzorca projektowego tylko dlatego, że istnieje i jest fantazyjny, z drugiej strony chciałbym używać dobrych wzorców i praktyk projektowych również dlatego, że pomaga projektować aplikację jako całość, pomaga w oddzieleniu obaw, nawet jeśli używanie określonego wzorca nie jest „konieczne”, przynajmniej w tej chwili.

Jak zawsze dziękuję.


28
Dla tych, którzy głosują za zamknięciem - czy zechciałbyś wyjaśnić, dlaczego chcesz zamknąć to pytanie jako oparte na opinii?
Robert Goldwein

20
@Aron „Code Review to witryna z pytaniami i odpowiedziami, służąca do udostępniania kodu z projektów, nad którymi pracujesz, do wzajemnej oceny” - moje pytanie w ogóle nie dotyczy kodu, więc byłoby tam nie na temat; SO: „Skoncentruj się na pytaniach dotyczących rzeczywistego problemu, z którym się spotkałeś. Dołącz szczegóły dotyczące tego, czego próbowałeś i dokładnie tego, co próbujesz zrobić”. - Mam konkretny problem ekspercki, który próbowałem rozwiązać. Czy mógłbyś sprecyzować, co jest nie tak w tym pytaniu, ponieważ wiele pytań tutaj dotyczy architektury i takie pytania są najwyraźniej w porządku, więc mogę uniknąć dalszych nieporozumień?
Robert Goldwein

7
Dziękuję, że zadałeś to pytanie. Zrobiłeś mi przysługę i uczyniłeś moje życie dużo prostszym i szczęśliwym, dziękuję.
Loa

9
@RobertGoldwein, nie przejmuj się SO Close Mafia, twoje pytanie jest uzasadnione.
hyankov

3
Wielkie dzięki za zadanie tego pytania
salman

Odpowiedzi:


177

nie wygląda dobrze, gdy model domeny opuszcza warstwę biznesową (warstwa usług)

Sprawia, że ​​czujesz, że wyciągasz flaki, prawda? Według Martina Fowlera: warstwa usług definiuje granice aplikacji, hermetyzuje domenę. Innymi słowy, chroni domenę.

Czasami usługa musi zwrócić obiekt danych, który nie został zdefiniowany w domenie

Czy możesz podać przykład tego obiektu danych?

Jeśli powinniśmy ściśle trzymać się DTO, czy powinny być zdefiniowane w warstwie usługowej?

Tak, ponieważ odpowiedź jest częścią Twojej warstwy usług. Jeśli jest zdefiniowane „gdzie indziej”, wówczas warstwa usług musi odnosić się do tego „gdzie indziej”, dodając nową warstwę do twojej lasagne.

czy można zwracać modele domeny aż do kontrolerów, czy też powinniśmy zawsze używać DTO do komunikacji z warstwą usług?

DTO jest obiektem odpowiedzi / żądania, ma sens, jeśli używasz go do komunikacji. Jeśli używasz modeli domeny w warstwie prezentacji (MVC-Controllers / View, WebForms, ConsoleApp), wówczas warstwa prezentacji jest ściśle powiązana z Twoją domeną, wszelkie zmiany w domenie wymagają zmiany kontrolerów.

wydaje się, że nie miałoby sensu tworzenie DTO, które jest takie samo jak model domeny)

Jest to jedna z wad DTO dla nowych oczu. W tej chwili myślisz o powielaniu kodu , ale w miarę rozwoju projektu miałoby to znacznie większy sens, szczególnie w środowisku zespołowym, w którym różne zespoły są przypisane do różnych warstw.

DTO może zwiększyć złożoność aplikacji, ale tak samo jak warstwy. DTO to kosztowna funkcja twojego systemu, nie są one darmowe.

Dlaczego warto korzystać z DTO

Ten artykuł przedstawia zarówno zalety, jak i wady korzystania z DTO, http://guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html

Podsumowanie w następujący sposób:

Kiedy użyć

  • Do dużych projektów.
  • Czas trwania projektu wynosi 10 lat i więcej.
  • Strategiczna aplikacja o znaczeniu krytycznym.
  • Duże zespoły (więcej niż 5)
  • Programiści są rozproszeni geograficznie.
  • Domena i prezentacja są różne.
  • Zmniejsz koszty wymiany danych (pierwotny cel DTO)

Kiedy nie używać

  • Mały i średni projekt (maksymalnie 5 członków)
  • Okres istnienia projektu to około 2 lata.
  • Brak oddzielnego zespołu ds. GUI, zaplecza itp.

Argumenty przeciwko DTO

Argumenty z DTO

  • Bez DTO prezentacja i domena są ściśle powiązane. (To jest dobre w przypadku małych projektów).
  • Stabilność interfejsu / API
  • Może zapewnić optymalizację warstwy prezentacji poprzez zwrócenie DTO zawierającego tylko te atrybuty, które są absolutnie wymagane. Używając linq-projection , nie musisz ciągnąć całego elementu.
  • Aby obniżyć koszty programowania, użyj narzędzi do generowania kodu

3
Cześć, dziękuję za odpowiedź, to naprawdę dobre podsumowanie, a także dzięki za linki. Moje zdanie „Czasami usługa musi zwrócić obiekt danych, który nie był zdefiniowany w domenie” było źle dobrane, oznacza to, że usługa łączy kilka DO z jednego repozytorium (np. Atrybuty) i tworzy jedno POCO jako kompozycję tych atrybutów (na podstawie logiki biznesowej). Jeszcze raz dziękuję za naprawdę miłą odpowiedź.
Robert Goldwein,

1
Ważną kwestią dotyczącą wydajności jest to, w jaki sposób te modele domeny lub DTO są zwracane z usługi. W przypadku EF, jeśli wykonujesz zapytanie zwracające konkretną kolekcję modeli domeny (na przykład z .ToArray () lub ToList ()), wybierz wszystkie kolumny, aby wypełnić zrealizowane obiekty. Jeśli zamiast tego projektujesz DTO w zapytaniu, EF jest wystarczająco inteligentny, aby wybrać tylko kolumny wymagane do wypełnienia DTO, co w niektórych przypadkach może być znacznie mniej danych do przesłania.
parsknij

10
Możesz mapować swoje obiekty „ręcznie”. Wiem, nudne rzeczy, ale zajmuje to 2-3 minuty na model i zawsze istnieje możliwość wprowadzenia wielu problemów, gdy używasz dużo refleksji (AutoMapper itp.)
Razvan Dumitru

1
dzięki za tak prostą i taką treść. Zrobiłeś mi przysługę i uczyniłeś moje życie dużo prostszym i szczęśliwym, dziękuję.
Loa

1
Mieliśmy anulować 10-milionowy projekt, ponieważ był zbyt wolny… Dlaczego był wolny? Przenoszenie obiektu DTO w dowolne miejsce za pomocą refelection. Bądź ostrożny. Automapper używa również odbicia.
RayLoveless

11

Wygląda na to, że Twoja aplikacja jest wystarczająco duża i złożona, ponieważ zdecydowałeś się przejść przez podejście DDD. Nie zwracaj swoich jednostek poco ani tak zwanych jednostek domeny i obiektów wartości w warstwie usług. Jeśli chcesz to zrobić, usuń warstwę usług, ponieważ już jej nie potrzebujesz! Obiekty widoku modelu lub transferu danych powinny znajdować się w warstwie usług, ponieważ powinny być mapowane na elementy składowe modelu domeny i odwrotnie. Dlaczego więc musisz mieć DTO? W złożonych aplikacjach z wieloma scenariuszami należy oddzielić zagadnienia dotyczące domeny i widoków prezentacji, model domeny można podzielić na kilka DTO, a także kilka modeli domen można zwinąć w DTO. Dlatego lepiej jest utworzyć DTO w architekturze warstwowej, nawet jeśli byłby taki sam jak model.

Czy zawsze powinniśmy używać DTO do komunikacji z warstwą usług? Tak, musisz zwrócić DTO przez swoją warstwę usług, ponieważ rozmawiasz ze swoim repozytorium w warstwie usług z członkami modelu domeny i mapujesz je na DTO i wracasz do kontrolera MVC i odwrotnie.

Czy można dostosowywać modele domen na podstawie potrzebnych usług? Usługa polega tylko na rozmowie z repozytorium i metodami domeny oraz usługami domenowymi. Powinieneś rozwiązać działalność w swojej domenie w oparciu o swoje potrzeby, a zadaniem usługi nie jest informowanie domeny, co jest potrzebne.

Jeśli powinniśmy ściśle trzymać się DTO, czy powinny być zdefiniowane w warstwie usługowej? Tak, spróbuj później uruchomić DTO lub ViewModel, ponieważ powinny być one mapowane na członków domeny w warstwie usług i nie jest dobrym pomysłem umieszczanie DTO w kontrolerach aplikacji (spróbuj użyć wzorca Request Response w warstwie Service), pozdrawiam !


1
przepraszam za to! możesz to zobaczyć tutaj ehsanghanbari.com/blog/Post/7/…
Ehsan

10

Z mojego doświadczenia wynika, że ​​powinieneś robić to, co praktyczne. „Najlepszy projekt to najprostszy projekt, który działa” - Einstein. Mając to na uwadze ...

jeśli ściśle używamy modeli widoku, czy można zwracać modele domeny aż do kontrolerów, czy też powinniśmy zawsze używać DTO do komunikacji z warstwą usług?

Absolutnie w porządku! Jeśli masz jednostki domeny, DTO i modele widoków, to włączając tabele bazy danych, wszystkie pola w aplikacji są powtórzone w 4 miejscach. Pracowałem nad dużymi projektami, w których encje domeny i modele widoków działały dobrze. Jedynym wyjątkiem jest sytuacja, gdy aplikacja jest rozproszona, a warstwa usług znajduje się na innym serwerze, w którym to przypadku DTO są wymagane do wysyłania przez sieć ze względu na serializację.

Jeśli tak, czy można dostosować modele domen w oparciu o potrzebne usługi? (Szczerze mówiąc nie sądzę, ponieważ usługi powinny zużywać to, co ma domena).

Generalnie zgodziłbym się i powiedziałbym nie, ponieważ model domeny jest zazwyczaj odzwierciedleniem logiki biznesowej i zwykle nie jest kształtowany przez konsumenta tej logiki.

Jeśli powinniśmy ściśle trzymać się DTO, czy powinny być zdefiniowane w warstwie usługowej? (Chyba tak.)

Jeśli zdecydujesz się z nich skorzystać, zgodzę się i powiem, że tak, warstwa usług jest idealnym miejscem, ponieważ pod koniec dnia zwraca DTO.

Powodzenia!


8

Spóźniłem się na to przyjęcie, ale jest to tak powszechne i ważne pytanie, że czułem się zmuszony do odpowiedzi.

Przez „usługi” masz na myśli „warstwę aplikacji” opisaną przez Evana w niebieskiej książce ? Ja zakładam, że zrobić, w tym przypadku odpowiedź brzmi, że powinny one nie powrócić DTOs. Proponuję przeczytać rozdział 4 w niebieskiej książce, zatytułowany „Isolating the Domain”.

W tym rozdziale Evans mówi o warstwach:

Podziel złożony program na warstwy. Opracuj projekt w każdej warstwie, który jest spójny i zależy tylko od warstw poniżej.

Jest ku temu dobry powód. Jeśli użyjesz koncepcji częściowego porządku jako miary złożoności oprogramowania, wtedy posiadanie warstwy zależy od warstwy nad nią, co zwiększa złożoność, co zmniejsza łatwość konserwacji.

Odnosząc się do twojego pytania, DTO to w rzeczywistości adapter, który jest przedmiotem zainteresowania warstwy interfejsu użytkownika / prezentacji. Pamiętaj, że komunikacja zdalna / międzyprocesowa jest dokładnie celem DTO (warto zauważyć, że w tym poście Fowler argumentuje również, że DTO jest częścią warstwy usług, chociaż niekoniecznie mówi w języku DDD).

Jeśli twoja warstwa aplikacji zależy od tych DTO, zależy to od warstwy nad nią, a twoja złożoność wzrasta. Mogę zagwarantować, że zwiększy to trudność w utrzymaniu oprogramowania.

Na przykład, co się stanie, jeśli Twój system będzie współpracował z kilkoma innymi systemami lub typami klientów, z których każdy wymaga własnego DTO? Skąd wiesz, która DTO metoda Twojej usługi aplikacji powinna zwrócić? Jak byś rozwiązał ten problem, jeśli wybrany przez ciebie język nie pozwala na przeciążanie metody (w tym przypadku metody serwisowej) opartej na typie zwracanym? A nawet jeśli znajdziesz sposób, po co naruszać warstwę aplikacji, aby wspierać problem związany z warstwą prezentacji?

W praktyce jest to krok w dół na drodze, która zakończy się architekturą spaghetti. Widziałem tego rodzaju decentralizację i jej rezultaty na podstawie własnego doświadczenia.

Tam, gdzie obecnie pracuję, usługi w naszej warstwie aplikacji zwracają obiekty domeny. Nie uważamy tego za problem, ponieważ warstwa interfejsu (tj. UI / Prezentacja) zależy od warstwy domeny, która znajduje się pod nią. Ponadto ta zależność jest zminimalizowana do typu zależności „tylko odwołanie”, ponieważ:

a) Warstwa interfejsu może uzyskać dostęp do tych obiektów domeny tylko jako wartości zwracane tylko do odczytu, uzyskane przez wywołania warstwy aplikacji

b) metody na usługach w Warstwie Aplikacji akceptują jako dane wejściowe tylko „surowe” dane wejściowe (wartości danych) lub parametry obiektów (w celu zmniejszenia liczby parametrów w razie potrzeby) zdefiniowane w tej warstwie. W szczególności usługi aplikacji nigdy nie akceptują obiektów domeny jako danych wejściowych.

Warstwa interfejsu wykorzystuje techniki mapowania zdefiniowane w samej warstwie interfejsu do mapowania obiektów domeny na DTO. Ponownie, to sprawia, że ​​DTO skupia się na byciu adapterami kontrolowanymi przez warstwę interfejsu.


1
Szybkie pytanie. Obecnie zastanawiam się, co wrócić z mojej warstwy aplikacji. Zwracanie jednostek domeny z warstwy aplikacji jest niewłaściwe. Czy naprawdę chcę ujawnić domenę „na zewnątrz”? Więc rozważałem DTO z poziomu aplikacji. Ale to dodaje kolejny model. W swojej odpowiedzi powiedziałeś, że zwracasz modele domen jako „wartości zwracane tylko do odczytu”. Jak to robisz? To znaczy, jak sprawić, by były tylko do odczytu?
Michael Andrews

Myślę, że przyjmuję twoje stanowisko. Usługi aplikacji zwracają modele domen. Następnie warstwy adapterów portów (REST, prezentacja itp.) Przekształcają je we własny model (model widoku lub reprezentacje). Dodanie modelu DTO między aplikacją a adapterami portów wydaje się przesadą. Zwracające modele domen nadal są zgodne z DIP, a logika domeny pozostaje wewnątrz ograniczonego kontekstu (niekoniecznie w granicach aplikacji. Ale wydaje się to dobrym kompromisem).
Michael Andrews

@MichaelAndrews, cieszę się, że moja odpowiedź pomogła. Odp .: Twoje pytanie, czy zwrócone obiekty są tylko do odczytu, same obiekty nie są w rzeczywistości tylko do odczytu (tj. Są niezmienne). Chodzi mi o to, że w praktyce tak się nie dzieje (przynajmniej z mojego doświadczenia). Aby zaktualizować obiekt domeny, warstwa interfejsu musiałaby a) odwołać się do repozytorium obiektu domeny lub b) wywołać ponownie warstwę aplikacji w celu zaktualizowania właśnie odebranego obiektu. Każde z nich jest tak wyraźnym naruszeniem dobrej praktyki DDD, że uważam je za wymuszone przez samego siebie. Jeśli chcesz, możesz zagłosować za odpowiedzią.
BitMask777

Ta odpowiedź jest dla mnie bardzo intuicyjna z kilku powodów. Po pierwsze, możemy ponownie użyć tej samej warstwy aplikacji dla kilku interfejsów użytkownika (interfejsów API, kontrolerów) i każdy z nich może przekształcić model według własnego uznania. Po drugie, gdybyśmy mieli przekształcić model do DTO w aplikacji. Warstwa, co oznaczałoby, że DTO jest zdefiniowane w App. Warstwa, co z kolei oznacza, że ​​DTO jest teraz częścią naszego ograniczonego kontekstu (niekoniecznie domeny!) - to po prostu źle się czuje.
Robotron

1
Miałem właśnie zadać dodatkowe pytanie, a potem zobaczyłem, że już na nie odpowiedziałeś: „usługi aplikacji nigdy nie akceptują obiektów domeny jako danych wejściowych”. Gdybym mógł, dałbym +1 ponownie.
Robotron

5

Spóźniłem się na imprezę, ale mam dokładnie ten sam typ architektury i skłaniam się ku „tylko DTO z serwisu”. Dzieje się tak głównie dlatego, że zdecydowałem się używać tylko obiektów / agregatów domeny, aby zachować ważność w obrębie obiektu, a więc tylko podczas aktualizacji, tworzenia lub usuwania. Kiedy wysyłamy zapytania o dane, używamy EF jako repozytorium i mapujemy wynik na DTO. Dzięki temu możemy swobodnie optymalizować zapytania odczytu i nie dostosowywać ich do obiektów biznesowych, często korzystając z funkcji bazy danych, ponieważ są one szybkie.

Każda metoda obsługi definiuje własną umowę i dlatego jest łatwiejsza do utrzymania w czasie. Mam nadzieję.


1
Po latach doszliśmy do tego samego wniosku, dokładnie z powodów, które tu wymieniłeś.
Robert Goldwein

@RobertGoldwein To świetnie! Teraz czuję się bardziej pewny swojej decyzji. :-)
Niklas Wulff

@NiklasWulff: tak więc te Dtos są teraz częścią kontraktu Application Layer, tj. Są częścią core / domain. A co z typami zwrotów interfejsu API sieci Web ? Czy ujawniasz Dtos wspomniane w Twojej odpowiedzi, czy masz dedykowane modele widoku zdefiniowane w warstwie Web API? Albo inaczej: czy mapujesz Dtos na View Models?
Robotron

1
@Robotron Nie mamy Web API, używamy MVC. Więc tak, mapujemy dto: s do różnych modeli widoku. Często model widoku zawiera wiele innych rzeczy do wyświetlenia strony internetowej, więc dane z dto: s stanowią tylko część modelu widoku
Niklas Wulff

4

Do tej pory używamy modeli domenowych (głównie encji) na wszystkich warstwach, a DTO używamy tylko jako modeli widoku (w kontrolerze usługa zwraca modele domeny, a kontroler tworzy model widoku, który jest przekazywany do widoku).

Ponieważ model domeny zapewnia terminologię ( język wszechobecny ) dla całej aplikacji, lepiej jest szeroko używać modelu domeny.

Jedynym powodem używania ViewModels / DTO jest implementacja wzorca MVC w Twojej aplikacji w celu oddzielenia View(dowolnego rodzaju warstwy prezentacji) i Model(Model domeny). W takim przypadku prezentacja i model domeny są luźno powiązane.

Czasami usługa musi zwrócić obiekt danych, który nie został zdefiniowany w domenie, a następnie albo musimy dodać nowy obiekt do domeny, która nie jest mapowana, albo utworzyć obiekt POCO (jest to brzydkie, ponieważ niektóre usługi zwracają modele domeny, niektóre skutecznie zwrócić DTO).

Zakładam, że mówisz o usługach Application / Business / Domain Logic.

Proponuję zwrócić jednostki domeny, kiedy tylko możesz. Jeśli konieczne jest zwrócenie dodatkowych informacji, można zwrócić DTO, który zawiera kilka jednostek domeny.

Czasami osoby, które używają frameworków trzeciej części, które generują proxy dla jednostek domeny, napotykają trudności w ujawnianiu jednostek domeny z ich usług, ale jest to tylko kwestia niewłaściwego użycia.

Pytanie brzmi - jeśli ściśle używamy modeli widoku, czy można zwracać modele domeny aż do kontrolerów, czy też powinniśmy zawsze używać DTO do komunikacji z warstwą usług?

Powiedziałbym, że w 99,9% przypadków wystarczy zwrócić podmioty domeny.

Aby uprościć tworzenie DTO i mapowanie do nich jednostek domeny, możesz użyć AutoMapper .


4

Jeśli zwrócisz część modelu domeny, stanie się on częścią umowy. Kontrakt jest trudny do zmiany, ponieważ zależą od niego rzeczy poza twoim kontekstem. W związku z tym utrudniłoby to zmianę części modelu domeny.

Bardzo ważnym aspektem modelu domeny jest to, że można go łatwo zmienić. To sprawia, że ​​jesteśmy elastyczni wobec zmieniających się wymagań domeny.


2

Proponuję przeanalizować te dwa pytania:

  1. Czy Twoje wyższe warstwy (tj. Wyświetlaj i przeglądaj modele / kontrolery) zużywają dane w inny sposób niż warstwa domeny? Jeśli jest dużo mapowania lub nawet logiki, zasugeruję zrewidowanie twojego projektu: prawdopodobnie powinno być bliżej sposobu, w jaki dane są faktycznie wykorzystywane.

  2. Jakie jest prawdopodobieństwo, że głęboko zmienisz swoje górne warstwy? (np. zamiana ASP.NET na WPF). Jeśli jest to bardzo odmienne, a Twoja architektura nie jest zbyt złożona, może być lepiej, jeśli ujawnisz jak najwięcej jednostek domeny.

Obawiam się, że jest to dość obszerny temat i tak naprawdę sprowadza się do tego, jak złożony jest Twój system i jakie są jego wymagania.


W naszym przypadku górna warstwa na pewno się nie zmieni. W niektórych przypadkach usługa zwraca dość unikalny obiekt POCO (zbudowany z większej liczby domen - np. Użytkownika i plików, które posiada), w niektórych przypadkach usługa zwraca po prostu model domeny - np. Wynik operacji „FindUserByEmail () powinien zwrócić model domeny użytkownika - i tutaj moje obawy, czasami nasze usługi zwracają model domeny, czasami nowe DTO - i nie podoba mi się ta niespójność, czytałem tyle artykułów, ile mogłem, i większość wydaje się zgadzać, że chociaż mapowanie modelu domeny <-> DTO to 1: 1, model domeny nie powinien opuszczać warstwy usług - więc jestem rozdarty.
Robert Goldwein

W takim scenariuszu i pod warunkiem, że możesz znieść dodatkowy wysiłek programistyczny, podjąłbym również mapowanie, aby Twoje warstwy były bardziej spójne.
jnovo

1

Z mojego doświadczenia wynika, że ​​jeśli nie używasz wzorca OO UI (jak nagie obiekty), ujawnianie obiektów domeny w interfejsie użytkownika jest złym pomysłem. Dzieje się tak, ponieważ wraz z rozwojem aplikacji potrzeby z interfejsu użytkownika zmieniają się i wymuszają na obiektach dostosowanie się do tych zmian. W końcu służysz 2 mistrzom: UI i DOMENA, co jest bardzo bolesnym doświadczeniem. Uwierz mi, nie chcesz tam być. Model UI ma funkcję komunikacji z użytkownikiem, model DOMAIN do przechowywania reguł biznesowych, a modele trwałości zajmują się efektywnym przechowywaniem danych. Wszystkie odpowiadają różnym potrzebom aplikacji. Jestem w trakcie pisania wpisu na blogu na ten temat, dodam go, gdy będzie gotowy.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.