Korzysta z obiektów transferu danych w ejb3 za najlepszą praktykę

Question

Chociaż oczywiście nie wszystkie scenariusze mogą być objęte jednym projektem, czy ogólnie uważa się, że klasy ORM powinny być przekazywane między warstwą prezentacji a warstwą biznesową (lokalnie lub zdalny), zastępując potrzebę obiektów transferu danych? O ile widzę, korzystanie z klas ORM stwarza problemy związane z niepotrzebnym obciążeniem, problemami z zarządzaniem kontekstem i ścisłym sprzężeniem, ale także oszczędza mnóstwo czasu i pozwala zachować prostotę. Czy istnieje obecnie standardowe podejście, które ogólnie faworyzuje jeden nad drugim (w większości sytuacji)?

Answer 1

Jest to bardzo interesujące pytanie, z którym badałem i eksperymentowałem w ciągu dwóch lat.

Myślę, że tak naprawdę nie ma tutaj żadnej poprawnej lub złej odpowiedzi. Nie sądzę, żebyś mógł po prostu powiedzieć, że chcę jeden nad drugim, ponieważ zazwyczaj możesz chcieć hybrydy w zależności od tego, co twoi klienci (strona internetowa, ws, maszyna i/lub lokalny, zdalny).

Ważne jest, aby pamiętać o tym, jakie są plusy i minusy każdej oferty i zastosować ją w oparciu o Twoje wymagania.

Dla przykładu:

• Jeśli uzywasz szew, wtedy chcesz uniknąć mocno warstwową architekturę, ponieważ masz dostęp do szerszym kontekście trwałości. Inne technologie internetowe bez tego wsparcia zwykle działają lepiej dzięki DTO, który przygotował stan z góry.
• Jeśli wysyłasz wiadomość zdalną, rzeczą importowaną jest, aby była cienka i lekka, zwykle funkcja DTO sprawdzi się lepiej niż obiekt domeny Rich. Tutaj możesz w sposób przezroczysty tłumić wszelkie problemy/zachowania ORM.
• Wzór DTO zapewnia ochronę klientów przed zmianami domeny. Jest to szczególnie ważne, jeśli twoja aplikacja jest usługą sieciową, posiadanie obiektu domeny (podmiotu), który definiuje twoją umowę, może w pewnym momencie pozostawiać Cię w spokoju.

Dzięki owijaniu systemu warstwami oraz ich dokładnemu udostępnianiu i zabezpieczaniu można tworzyć różne interfejsy API dla wielu klientów różnych typów.

Answer 2

Myślę, że istnienie DTO jest związane z JPA/Hibernate wady. Jeśli zawsze możesz wykonać przezroczystą, leniwą inicjalizację, nigdy jej nie użyjesz. Używanie DTO to kontrakt, w którym moja domena/obszar roboczy zawsze gubi się (wszędzie duplikacja). Podsumowując, możesz ich używać, ale musisz ich nienawidzić :)

Answer 3

Ciasne sprzężenie? Proszę wytłumacz.

Jeśli chodzi o mnie, DTO to anty-wzór. EJB3 pozwala nam pominąć ich używanie. Możesz po prostu wymusić swoją leniwą inicjalizację przed wysłaniem Entity do klienta.

Oczywiście, jeśli potrzebujesz tylko dwóch z 30 pól do wysłania do klienta, który właśnie wysłałeś. Ale jeśli całość jest kopiowana przez cały czas, tak jak w moim obecnym projekcie - spróbuj pozbyć się tego DTO. Nie widzę powodu, aby z nich korzystać. Wysyłasz obiekt biznesowy do klienta, jak zapytał klient. Dlaczego warto korzystać z opakowania?

Answer 4

Zgadzam się z ostatnim "głośnikiem", dlaczego warto korzystać z opakowania w ejb3? Budujemy dość złożony system bez DTO, ale używając Entities (JPA) udało się go znaleźć. Było jasne ...

Answer 5

Praca tylko z jednostkami byłaby w porządku, jeśli kontroler GUI wysyła obiekty własności do formularzy, a nie obiektów obiektu.Z drugiej strony, jeśli używane są jednostki i te jednostki mają relacje wiele do jednego, to należy się spodziewać pewnych nieprzyjemnych wyjątków, jeśli podmioty nie są chętnie pobierane przez podmiot zarządzający.

Takie sytuacje można zaobserwować przy próbie wypełnienia tagów Spring MVC lub podobnych konstrukcji innych komponentów GUI.

Ponadto DTOs są bardzo dobrym miejscem na umieszczenie dodatkowych adnotacji, takie jak adnotacje walidacji lub JAXB itp

Answer 6

Mam kilka problemów przed użyciem jednostek w warstwie prezentacji:

• lock-in: To ostatecznie tworzy ścisłą blokadę między prezentacją a modelem. Zmiana w dużych projektach staje się kosztowna, wręcz niemożliwa. Nowoczesne narzędzia nie są jeszcze na miejscu.

• Zabezpieczenia: W przypadku obiektów modelu można łatwo przenosić różne informacje o identyfikatorach baz danych na strony internetowe. Jest to wyraźny problem z bezpieczeństwem. Używając dto:s możesz ukryć te dane na serwerze z bardzo prostymi mapami sesji.

• Różnica potrzeb: Rzuty GUI rzadko są bezpośrednimi listami obiektów modelu. Częściej są czymś więcej, połączonymi zwierzętami, Guish. Potrzeby GUI mają tendencję do wślizgiwania się do twojego modelu, który go zaciemnia.

• Prędkość: W przypadku elementów każde pole jest przetwarzane za każdym razem, gdy je czytasz/zapisujesz. Ponieważ przekazujesz je bezpośrednio do warstwy prezentacji, masz trudności z optymalizacją swoich zapytań JPA - prawie niemożliwe. Zdecydowanie wrócę do bezpośredniego dostępu do JDBC - jak myBatis w przyszłych projektach. W ten sposób eliminując ORM.

mam problemy przeciwko DTO:s TOO:

• dodatkowy kod DAO.

Rzeczy uwzględnione, będę głosować za używanie dto:s dla wszystkich projektów, eliminując również JPA. Tak, mój stos staje się coś takiego:

• myBatis dla dostępu do bazy danych
• POJO jak DTO: s
• Stateless EJB dla moich usług DAO.
• StatefulEJB dla interfejsu GUI.
• JSF do prezentacji.