Sam się z tym zmagałem. Są przypadki, w których DTO ma sens w prezentacji. Powiedzmy, że chcę wyświetlić listę firm w moim systemie i potrzebuję ich identyfikatora, aby powiązać wartość.
Cóż, zamiast ładować CompanyObject, który może mieć odniesienia do subskrypcji lub kto wie, co jeszcze, mógłbym odesłać DTO z nazwą i identyfikatorem. To jest dobre zastosowanie IMHO.
Weźmy teraz inny przykład. Mam obiekt, który reprezentuje oszacowanie, to oszacowanie może składać się z robocizny, wyposażenia itp., Może mieć wiele obliczeń, które są zdefiniowane przez użytkownika, które biorą wszystkie te pozycje i podsumowują je (każde oszacowanie może być różne dla różnych typów obliczeń). Dlaczego powinienem dwukrotnie modelować ten obiekt? Dlaczego nie mogę po prostu wyliczyć mojego interfejsu użytkownika na obliczeniach i wyświetlić je?
Generalnie nie używam DTO do odizolowania warstwy domeny od interfejsu użytkownika. Używam ich do odizolowania warstwy domeny od granicy, która jest poza moją kontrolą. Pomysł, że ktoś umieści informacje nawigacyjne w swoim obiekcie biznesowym, jest śmieszny, nie zanieczyszczaj tego obiektu biznesowego.
Pomysł, że ktoś umieściłby walidację w swoim obiekcie biznesowym? Cóż, mówię, że to dobra rzecz. Twój interfejs użytkownika nie powinien odpowiadać wyłącznie za weryfikację obiektów biznesowych. Twoja warstwa biznesowa MUSI przeprowadzić własną walidację.
Dlaczego miałbyś umieścić kod generujący interfejs użytkownika w obiekcie busienss? W moim przypadku mam osobne obiekty, które generują kod UI oddzielnie od UI. Mam oddzielne obiekty, które renderują moje obiekty biznesowe w XML, pomysł, że musisz oddzielić warstwy, aby zapobiec tego typu zanieczyszczeniu, jest dla mnie tak obcy, ponieważ po co w ogóle umieszczać kod generujący HTML w obiekcie biznesowym ...
Edycja
Myślę, że trochę więcej, ale są przypadki, w których informacje o interfejsie użytkownika mogą znajdować się w warstwie domeny. Może to spowodować zachmurzenie tego, co nazywasz warstwą domeny, ale pracowałem nad aplikacją dla wielu dzierżawców, która miała bardzo różne zachowanie, zarówno w wyglądzie, jak i funkcjonalnym przepływie pracy. W zależności od różnych czynników. W tym przypadku mieliśmy model domeny, który reprezentował dzierżawców i ich konfigurację. Ich konfiguracja zawierała informacje o interfejsie użytkownika (na przykład etykiety dla pól ogólnych).
Gdybym musiał zaprojektować moje obiekty tak, aby były trwałe, czy powinienem również powielić te obiekty? Pamiętaj, że jeśli chcesz dodać nowe pole, masz teraz dwa miejsca na dodanie go. Być może rodzi to kolejne pytanie, czy używasz DDD, czy wszystkie obiekty domeny utrwalonych jednostek? Wiem na moim przykładzie, że tak było.