Jaka jest najlepsza praktyka w korzystaniu z jednostek JPA?JPA POJO jako obiekt danych
Ponieważ jednostki JPA są po prostu obiektami POJO, czy uważa się za stosowne użycie obiektu jako obiektu danych w innych częściach systemu, czy też powinienem go przekonwertować na inny obiekt danych?
Czy dopuszczalne jest używanie POJO Entity JPA Entity w innych częściach systemu niezwiązanych z JPA?
Jednostki są teraz same zdolne do przenoszenia własnych danych, więc po co zamieniać je na coś innego? Innymi słowy, mają tendencję do uzgodnienia z DTO an AntiPattern in EJB 3.0:
ciężarem charakter ziaren podmiotów w specyfikacji EJB przed EJB 3,0, w wyniku wykorzystania desenie jak Data Transfer Objects (DTO). DTO stały się lekkimi obiektami (które w pierwszej kolejności powinny być elementami bean obiektu), wykorzystywanymi do przesyłania danych na różnych poziomach. [...]
Specyfikacja EJB 3.0 sprawia, że model komponentu Entity jest taki sam jak zwykły stary obiekt Java (POJO). Dzięki temu nowemu modelowi POJO nie będziesz już musiał tworzyć DTO dla każdej jednostki ani dla zestawu jednostek. Jeśli chcesz wysłać obiekty EJB 3.0 w warstwie, spraw, aby były one po prostu zaimplementowane:
java.io.Serialiazable.
To zależy od tego, co masz na myśli z "innymi częściami". Ponieważ Twoje Jednostki WZP muszą być w jakiś sposób powiązane z twoim systemem, dlaczego nie używać ich, ponieważ już tam są. Ważne jest to, że nie używasz tej samej klasy dla dwóch całkowicie różnych zagadnień (które są wtedy albo oznaką złego projektu, albo tylko naprawdę dużego systemu). Wszystko inne prawdopodobnie skończy się niekończącym się mapowaniem pomiędzy różnymi problemami POJO.
Na przykład użytkownik Zaloguj się. Może być powszechną, obcą praktyką Java tworzenie osobnego UserLoginForm Bean dla logowania przez Internet, ale rozważ to:
Masz już swoje jednostki JPA użytkownika (a zatem użytkownika POJO) w bazie danych (ma ona nazwę użytkownika, hasło hash, adres i prawdopodobnie inne przechowywane rzeczy). Możesz użyć dokładnie tego samego obiektu w żądaniu logowania z formularza internetowego (niektóre frameworki, takie jak Spring, od razu je zmapują). Utwórz pusty obiekt użytkownika, ustaw nazwę użytkownika i hashowane hasło i wykonaj kwerendę JPA według przykładu. Jeśli zapytanie zwróci dokładnie jeden wynik, logowanie jest prawidłowe i można zapisać załadowany obiekt użytkownika w sesji.
To jest dobre pytanie.
Ujawniając klasy jednostek JPA do reszty systemu, ujawniasz mechanizm utrwalania i obiekt do mapowania db. Stracisz kontrolę nad tym, jak te obiekty są CRUDded i zarządzane. Poprzez przerwanie enkapsulacji trwałości zmiana może mieć wpływ na pozostałą część systemu.
Przyszłe zmiany w trwałości systemu mogą być niemożliwe, niewygodne, ograniczone i/lub ryzykowne. Przykład: być może trzeba będzie zoptymalizować pod kątem wydajności i/lub skalowalności. Może to wymagać buforowania, zmian schematu bazy danych, braku użycia RDBMS, wielu baz danych. Enkapsulacja pomaga również w ograniczeniu migracji do przyszłych schematów db.
więc kompromis jest:
Pierwsza opcja może być konieczna, jeśli częste zmiany w całym systemie są niedopuszczalne - np. Firmy zewnętrzne uzyskują dostęp do twoich danych. A może zdecydowałeś się na architekturę trójwarstwową: GUI, logikę biznesową, trwałość.
Druga opcja jest OK, jeśli masz sprawny proces rozwoju i masz kontrolę nad całym systemem i akceptujesz fakt, że zmiana całego systemu może być konieczna w linii.
Udzielając odpowiedzi, ponieważ łączyłeś się z interesującą dokumentacją antypaterynkową. – Tazzy531