Czy korzystanie z obiektów obiektu na wszystkich warstwach aplikacji WWW jest złym rozwiązaniem?

Question

Zajmuję się tworzeniem aplikacji internetowych przy użyciu warstwowej architektury. Mam:

1. Application Layer (Sterowniki)
2. usługi Layer (Services)
3. Data Access Layer (DAOS)

który łączy się z bazą danych Oracle backend.

Używam JPA z Hibernate jako wdrożenie. Dlatego tworzę obiekty do modelowania widoku obiektów moich relacyjnych tabel bazy danych.

Moje pytanie brzmi ... Czy korzystanie z tych obiektów jest uważane za złą praktykę we wszystkich trzech warstwach?

Wiem, że to musi być używane przez warstwę dostępu do danych co najmniej, ale co dalej poza tym w Warunkach aplikacji &?

Widziałem, jak niektórzy ludzie używają DTO w warstwach aplikacji & zamiast tego i dokonują konwersji między DTO a jednostkami między warstwami dostępu do usługi &.

Zastanawiasz się, jaka jest najlepsza praktyka w tym przypadku i jakie powinno być najlepsze podejście?

Answer 1

Nigdy nie należy używać obiektów obiektu na wszystkich warstwach. Używając tego samego obiektu na całej warstwie, tworzymy ścisłe powiązanie między twoimi danymi UI a tabelami bazy danych.

Jeśli chcesz zmienić nazwę pola w interfejsie użytkownika, musisz zmodyfikować odpowiednią kolumnę w tabeli. Dlatego zaleca się DTO, VO do przenoszenia danych z DAO do twojego interfejsu. Użyj różnych typów maperów dostępnych na rynku. Jednym z przykładów jest orika mapper.

Answer 2

Istnieją przypadki, gdy obiekty danych pasują dokładnie do obiektów, którymi manipuluje użytkownik na ekranie. Z drugiej strony zdarzają się sytuacje, w których użytkownik pracuje nad obiektami, które zostały wyprowadzone i/lub wpływają na wielokrotność zgodnie z logiką biznesową. Wiele aplikacji do raportowania to przykłady tego ostatniego.

W zależności od domeny i profilu użytkownika częstotliwość dopasowywania przypadków obiektów danych/UI jest wysoka lub niska. W razie potrzeby należy zdefiniować oddzielne modele i wiąże się to z kosztami ich utrzymania poprzez zmiany w projekcie. W związku z tym nadmiernie rozdzielone modele stanowią złą praktykę. Z drugiej strony, jeśli nalegasz na przekazywanie modeli danych wszędzie, logika biznesowa lub kod UI mogą nie być bardzo czyste.

Decyzja o oddzieleniu obiektów warstwy dostępu do danych od tych przekazywanych do interfejsu użytkownika zależy również od używanych narzędzi. Na przykład w przypadkach, w których kontrolery serializują w JSON w sposób statyczny (*), można wybrać definicję klas dla każdego drzewa przejścia (do użycia) wykresu obiektu. Z drugiej strony te same obiekty mogą być użyteczne z interfejsem opartym na JSP.

(*) Przykładem jest jackson, który wykorzystuje adnotacje, które naprawiają sposób serializacji obiektu (wykresu) w drzewie. Istnieją sposoby na ograniczenie drzewa - użyteczne w zapobieganiu niepożądanym wyciekom danych - jednak ich praktyczność i łatwość konserwacji jest ograniczona w przypadku napotkanych problemów.