Dto czy obiekt modelu domeny w warstwie widoku?
Wiem, że to prawdopodobnie odwieczne pytanie, ale jaka jest lepsza praktyka? Używanie obiektu modelu domeny we wszystkich warstwach aplikacji, a nawet Wiązanie wartości bezpośrednio do nich w JSP (używam JSF). Możesz też przekształcić obiekt modelu domeny w DTO w warstwie DAO lub Service i wysłać lekki DTO do warstwy prezentacji.
Powiedziano mi, że nie ma sensu używać DTOs, ponieważ zmiany w bazie danych spowodują zmiany we wszystkich Twoich DTOs, podczas gdy używanie Obiekty modelu wszędzie będą wymagały jedynie zmian w danym obiekcie modelu. Jednak wydaje się, że łatwość użytkowania i lekki charakter DTOs przeważają nad tym.
Powinienem zauważyć, że moja aplikacja używa obiektów modelu Hibernate i używa własnych, niestandardowych obiektów modelu (czyli nie związanych z żadną sesją DB, zawsze odłączonych). Czy któryś z powyższych scenariuszy jest bardziej korzystny dla ścisłego wzorca obiektów modelu? Korzystanie z Hibernate było ogromną PITA w odniesieniu Do Rzeczy Takich jak leniwy Wyjątki Inicjalizacji.
Edytuję to pytanie w nadziei na dalszą dyskusję (Nie wiem, czy robię to dobrze):
Problem, jaki mam z obiektami modelowymi, polega na tym, że nie są one w ogóle elastyczne. Poniższy komentarz mówi, że aplikacja powinna być zaprojektowana tak, aby obiekty modelu mogły być używane na wszystkich warstwach. Dlaczego? Jeśli użytkownik chce kawałka śmiesznej funkcjonalności, to mam mu powiedzieć: "Cóż, to nie zadziała z obiektami modelowymi"?
Zwykły i proste, są chwile, kiedy obiekty modelu nie będą działać. Możesz mieć:
public class Teacher {
List<Student> students;
[tons of other Teacher-related fields]
}
public class Student {
double gpa;
[tons of other Student-related fields]
}
Może to zabrzmieć tak, jakby mój umysł został podjęty, ale muszę jeszcze pracować w aplikacji, w której obiekty modelu mogą być całkowicie używane w każdym przypadku. Zwykłe aplikacje w świecie rzeczywistym z nietypowymi wymaganiami użytkowników po prostu nie działają w ten sposób.
8 answers
To naprawdę zależy od złożoności aplikacji. Mieszanie obiektów domeny z warstwą widoku ma dwa możliwe implikacje:
- będziesz musiał zmodyfikować obiekt domeny, aby dostosować go do potrzeb w warstwie widoku
- Twoja warstwa widoku będzie zawierać dodatkową złożoność spowodowaną niedopasowaniem między tym, co oferują obiekty domeny, a tym, czego naprawdę potrzebuje twój widok. Możesz nie być w stanie obejść tej złożoności, ale prawdopodobnie nie należy do widoku warstwa.
Jeśli obiekty domeny są proste, a widoki są nieliczne, pomijanie DTOs może być najprostszą rzeczą.
Z drugiej strony, jeśli twój model domeny może ewoluować i stać się złożony oraz jeśli Twoje widoki mogą być liczne i zróżnicowane, posiadanie konkretnych obiektów widoku może być dobrym pomysłem. W świecie MVC używanie ViewModels jest powszechne i ma dla mnie duży sens.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-09-27 15:40:59
Kolejny głos na obiekty domeny. Jeśli chodzi o Domain Driven Design, model domeny jest królem i powinien być stosowany tam, gdzie to możliwe. Aplikacja powinna być zaprojektowana w taki sposób, aby większość warstw (warstwa infrastruktury bar) mogła korzystać z obiektów domeny.
Myślę o DTOs jako użytecznym tylko tam, gdzie obiekty muszą być serializowane. Jeśli nie ma transferu przez przewód lub do niekompatybilnej architektury, nie używałbym ich. Wzór DTO jest przydatny do utrzymania serializacji z obiekt domeny. Biorąc pod uwagę, że interakcja UI/Domena nie wymaga serializacji, zachowaj ją w prosty sposób i używaj rzeczywistych obiektów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-04-21 03:32:25
Myślę, że posiadanie DTO nie jest generalnie anty wzorcem. Korzysta z nich wiele osób i systemów, a zaletą jest odsprzęgnięta warstwa widoku, która może być zaprojektowana i modularna niezależnie od modelu domeny. Chociaż zgadzam się, że należy używać obiektów domeny, gdzie to możliwe, istnieją scenariusze, w których można uzyskać problemy, gdy powiązać warstwę widoku bezpośrednio z modelem domeny.
Mam dobre doświadczenia z modelem widoku, który otacza tylko domenę obiektów i deleguje im większość operacji.To oddziela widok i warstwę domeny, pozwala na elastyczną kompozycję obiektów domeny i nadal nie ma wiele pracy do wdrożenia, ponieważ IDE obsługują wzór delegacji.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-30 14:26:37
Scenariusze, gdy obiekt domeny jest problematyczny do wysłania:
- możesz potrzebować zagregowanych informacji lub innych typów "pól obliczeniowych" wysyłanych do warstwy interfejsu użytkownika (w przykładzie Flex / GWT ) i nie chcesz mieszać obiektu domeny
- możesz napotkać potrzebę serializacji cyklicznego wykresu obiektów (w twoim przykładzie, jeśli uczeń miał relację List ) , niektóre protokoły mają z tym problemy
- Hibernate LazyInitializationException przy radzeniu sobie z serializerami framework (blazeDS for Flex / GWT serializer)
Nie jestem pewien, czy to jest jasna odpowiedź w tych cirumcstances
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-07-10 19:44:55
Moim zdaniem nie ma problemu z używaniem obiektów modelu domeny w każdej warstwie. Powiedziałeś, że nie potrzebujesz wszystkich informacji. Gdy korzystasz z JSP, używaj tylko tych danych, których potrzebujesz. Nikt nie zmusza cię do pobierania każdej nieruchomości. Powiedziałeś również, że musisz wykonać obliczenia związane z właściwościami obiektu, aby uzyskać średnią ocen, # uczniów itp. Masz 3 opcje: Utwórz syntetyczne właściwości w obiekcie modelu domeny, które zwracają odpowiednie dane, owinięte ładnie i schludnie; wykonuj obliczenia w warstwie kontrolera lub usługi i wystawiaj je za pomocą odpowiednich getterów; lub obsługuj to wszystko w swoim JSP. Musisz pobrać/skompilować / wrangle dane Tak, więc dlaczego dodać więcej złożoności z DTO.
DODATKOWO, z każdym DTO, tworzysz a.) dodatkową klasę, którą musisz teraz utrzymywać, oraz b.) co najmniej 1 dodatkową metodę gdzieś w jakiejś klasie, która konstruuje i wypełnia DTO (DAO, metoda fabryczna itp.). Więcej konserwacja = niezadowolony deweloper 6 miesięcy później.
Oto moje argumenty przeciwko DTOs. Używam ich, ale tylko w niektórych scenariuszach, na przykład gdy naprawdę muszę zoptymalizować szybkość i / lub zużycie pamięci, a koszt nawadniania obiektu modelu pełnej domeny jest o wiele za duży. Usługi internetowe są dobrym przykładem, kiedy wolę używać DTOs.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-04-10 06:00:00
Zachowanie klasy lub jej wewnętrznych metod nie powinno być narażone na warstwy nie zajmujące się ich zachowaniem. Transfer danych, nie zachowania. Użyj obiektów domeny w obrębie domeny. Web nie jest kontrolowaną domeną, a programiści interfejsu nie muszą martwić się o zachowanie domeny, tylko danymi.
Domena musi być zamknięta i zabezpieczona przed modyfikacją przez kogoś, kto nie jest zainteresowany zdrowiem domeny.
Przeciekanie nie jest najlepsze przyzwyczajenie.
Jeśli jest to mały projekt, zbuduj go z poprawnymi principes, jak również. W ten sposób zawsze pamiętamy, dlaczego robimy to, co robimy, a nie tylko jak.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-03-23 17:57:29
Myślę, że powinniśmy wziąć pod uwagę przede wszystkim koszt wprowadzenia nowej warstwy. Weźmy na przykład DTO - w tym celu potrzebujemy mapowania. Jak ktoś powiedział, tłumaczenie jest złe i powinno być unikane w miarę możliwości.
Z drugiej strony myślę, że jest bardzo niewiele rzeczy, których generalnie nie powinieneś robić. Ci, którzy mówią, że wszystkie Dto są złe, są w błędzie - to zawsze zależy od przypadku użycia! Czy naprawdę są uzasadnione?
I na koniec osobiście wierzę, że domena obiekty powinny być puszczane do samego widoku. Wyobraź sobie, jak wygląda integracja bramki. Ale weźmy na przykład Spring MVC-domena zostałaby wtedy prawdopodobnie w warstwie aplikacji...
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-08-18 07:37:40
DTO jest powszechnie uważany za anty-wzorzec w dzisiejszych czasach, a rada jest zwykle "unikaj ich za wszelką cenę".
Jedną z głównych zalet frameworka ORM, takiego jak Hibernate, jest to, że możesz używać obiektów domeny na wszystkich poziomach i tak naprawdę nie potrzebujesz DTOs. Zastrzeżenie jest oczywiście takie, że trzeba poświęcić trochę czasu na zastanowienie się nad tymi relacjami: kiedy korzystać z leniwego pobierania, kiedy używać chętnych itp.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-04-21 03:22:10