2012-06-28 31 views
10

W kompletnej aplikacji Java EE, która jest klastrowana, wzór DTO nadal jest prawidłową opcją? Ta aplikacja używa EJBs Hibernate i Struts with Spring itd. Czy coś jest nie tak z przenoszeniem obiektów domeny w takim scenariuszu?Czy wzór DTO jest przestarzały, czy nie?

EDYCJA: Tylko po to, aby wyjaśnić moje pytanie, dzięki współczesnym zasobom i ulepszeniom w Java EE jest powód, aby nie używać tylko obiektów domenowych? Jeśli tak nie jest, to nie ma mowy o wygaszaniu wzoru DTO i nie powinno być używane w nowych aplikacjach?

Odpowiedz

19

Nie jest przestarzałe. Zależy to od architektury aplikacji, jeśli należy zastosować wzór DTO. Na przykład, gdy tworzysz usługi sieciowe (używając JAX-WS lub JAX-RS), powinieneś wysłać DTO za pośrednictwem swoich metod sieciowych, aby aplikacja kliencka C# lub Python mogła je zużywać, a twoja metoda sieciowa nie powinna zwracać obiektu, którego klasa ma Adnotacje w stylu hibernacji, pamiętajcie, że w innych językach nie można utworzyć encji z tymi adnotacjami lub inną logiką biznesową wewnątrz.


EDYCJA (na podstawie komentarza): To zależy od architektury oprogramowania. Na przykład pracuję nad projektem SOA i używamy DTO dla warstwy usług i warstwy prezentacji. Im głębiej wewnątrz, używamy nawet DTO do obsługi komunikacji z bazami danych w usługach, używamy tylko SP do komunikowania się z DB, więc żadne Hibernacja ani żadne inne narzędzia ORM nie mogą tam pracować, moglibyśmy użyć Spring DAO, a ta struktura również używa DTO. W wielu aplikacjach można znaleźć wiele wzorców DTO.

Więcej informacji, że byłoby świetnie na to pytanie:

EDIT 2: Innym źródłem informacji, które wyjaśnią Głównym powodem wykorzystania wzornictwa dto jest, wytłumaczyć Martin Fowler

Wniosek: DTO użytkownika nie jest to anty wzór. DTO mają być używane tylko wtedy, gdy musisz przekazać dane z jednego podsystemu do innego i nie mają standardowego lub standardowego sposobu komunikowania się.

+0

Tak, w takim scenariuszu rozumiem korzystanie z DTO. Wysyłasz wyniki do DTO. Ale do zastosowania wewnętrznego aplikacji DTO nie są zbyt przydatne, prawda? – Thihara

+0

@ Thihara odpowiedź edytowana na podstawie Twojego komentarza –

+0

Według twojego pierwszego, jak to jest anty wzór używany do obejścia faktu, że fasole encji nie można szeregować. W przypadku ORM podstawowy problem nie istnieje. – Thihara

1

Wzór to czysty wzór. Nie ma "wycofywania" wzorca, ale mniejsze zużycie w czasie (lub nadmierne zużycie).
Osobiście nie rozumiem, dlaczego nie używać DTO.
Na przykład - w projekcie o otwartym kodzie źródłowym pod adresem oVirt mamy podmioty reprezentujące podmioty logiki biznesowej w domenie wirtualizacji.
Podmioty te powinny być opatrzone przypisami Hibernacji (w rzeczywistości są one dzisiaj, gdy rozpoczęliśmy pracę z hibernacyjnymi dokumentami POC) i pełnią funkcję DTO, a następnie mają czyste obiekty adnotacji, które zostaną do nich przyporządkowane (powiedzmy, używając dozer framework) i używane przez klienta
(Nie lubię mieć po stronie klienta kodu z niepotrzebnymi adnotacjami), lub podmioty powinny służyć jako obiekty klienta (obiekty wartości) przekazywane do klienta i powinniśmy mieć inne klasy służyć jako Jednostki DTO:

Minusem w powyższym podejściu jest to, że możesz mieć 2 równoległe diagramy klas - jeden dla DTO i jeden dla obiektów wartości (używanych przez klientów) - ale w wielu przypadkach w projektowaniu istnieje wymiana handlowa. poza.
Musisz zrozumieć zalety i wady i wybrać to, co jest dla ciebie najlepsze (w naszym przypadku, ponieważ strona klienta jest GWT, łatwiej będzie nam przejść do separacji do dwóch hierarchii klas, po stronie DTO/serwera i może być również przypisany z większą ilością adnotacji po stronie serwera, a drugi wysyłany do kodu klienta GWT).

+0

Przednia część nie jest GWT, gdzie ja to sugerowałem? To JSP z dużą ilością javascript i jQuery. Tak, zaske, o co pytam, to czy jest sens używania ich, ponieważ współczesne modele obiektów są tym, co trzyma dane. – Thihara

2

Jest to bardzo przydatny wzór w Java EE.

Używam DTO do przesyłania obiektów powiązanych obiektów z komponentów EJB do warstwy interfejsu użytkownika. Obiekty obiektu są pobierane z DB w jednej transakcji (patrz TransactionAttributeType.REQUIRED) i przechowywane w obiekcie DTO. DTO to zużyte w warstwie interfejsu użytkownika.

Powiązane problemy