Korzystanie DAOs z kompozytowych Objects

Próbuję przepisać kilka DAOs Oto ustawienie:Korzystanie DAOs z kompozytowych Objects

tylko zwykły JDBC (nr JPA, ORM w ogóle)
żadne interfejsy wykorzystywane
wiele kontroli przed włożeniem obiekt
obiekty biznesowe są silnie powiązane

Moje główne pytanie brzmi: Jak Persi st/pobierz obiekt biznesowy złożony z wielu innych obiektów? np. czy moja CustomerDAO zna adresDAO i odbiera adresy adresatów?

Źródło

2012-09-09 er4z0r

Spójrz na [jcabi-jdbc] (http://www.jcabi.com/jcabi-jdbc), jest to lekkie opakowanie JDBC (jestem programistą) – yegor256

tylko zwykły JDBC (nr JPA, ORM w ogóle) Obiekty biznesowe są silnie powiązane

Nie wiem, dlaczego nie chcesz korzystać z JPA natomiast chcesz, aby obiekty biznesowe mają być połączone, ale przynajmniej powinieneś użyć szablonu Spring JDBC, który zwalnia cię z jakiegoś kodu standardowego.

Odnośnie innych ograniczeń, chciałbym zrobić to w następujący sposób:

bym nadal zatrudniać interfejsy określające metody DAO i wdrażania ich w szablonie Wiosna JDBC backed DAOImpl. Użyj DAO wszędzie i wstrzyknij DAOImpl.
Moje DAO będą po prostu odwzorowaniem jeden do jednego na podstawowe tabele i każdy DAO nie będzie wiedział o istnieniu innych DAO.
Warstwa My Manager będzie zawierała logikę biznesową, która uruchamia sprawdzanie poprawności i przygotowuje zestaw obiektów, które muszą być utrwalone, wywołuje odpowiednią metodę DAO i odpowiednią metodę (CREATE/UPDATE/DELETE), aby utrwalić obiekty.
Ponownie, warstwa Menedżera będzie postępować zgodnie z implementacją opartą na interfejsie, a warstwa widoku będzie miała typy menedżerów wstrzykiwane za pomocą ManagerImpls.

Moje dwa centy!

Źródło

2012-09-09 13:03:52 Vikdor

Dzięki! Myślałem o JPA. Do tej pory kontrargument polegał na tym, że ta aplikacja nie jest w żaden sposób solidnie zaprojektowana i nie jestem pewien, jak działałyby prace nad JPA. (To nie działa nawet na serwerze aplikacji!). Jednak jeśli dostanę odpowiednie punkty 2-4, zasadniczo oznacza to, że zakodowuję swój własny podmiot zarządzający, prawda? – er4z0r

Zgadza się, twoja warstwa menedżera będzie miała wiedzę na temat powiązań między różnymi obiektami domeny (np. Klient, adres) itd. Jeśli użyłeś specyfikacji JPA do zdefiniowania swoich podmiotów i ich powiązań i zatrudniłeś dostawcę JPA (jak Hibernate), zadbali o utrzymanie hierarchii obiektów i moglibyśmy skoncentrować się na transferze obiektów domenowych. – Vikdor

Możesz rozważyć użycie JOOQ. To nie jest JPA, ale może być łatwo wykorzystane jako alternatywne rozwiązanie. Jest wystarczająco lekki. Zapewnia również narzędzie inżynierii odwrotnej, w którym buduje obiekty bazy danych jako obiekty DAO.

Umieściłem JOOQ w odpowiedniej sytuacji, w której aplikacja została zaprojektowana w sposób dość skonstruowany. Nie używałem jego funkcji DAO, zamiast używać jej jako wyższej warstwy, aby uniknąć bałaganu w warstwie JDBC.

Pozdrawiam!

Źródło

2012-09-09 13:51:26

Podmioty złożone to warstwa ponad DAO. Jeśli chcesz usunąć WSZYSTKIE sprzężenie, obiekty domeny utrwalone przez DAO powinny być płaskie bez relacji. Zobacz Wzorce Core J2EE CompositeEntity.

Poza tym dobrze jest nie wprowadzać sprzężenia między DAO, umieszczając szukacze w jednym z nich. Np .:

AdresDAO.findForCustomerId (id);

jest gorszy od używania trzeciego DAO do zarządzania relacją. I.E:

CustomerAddressRelDAO.findAddressForCustomer (id);

Jeśli korzystasz z relacji DAO, ani adres, ani klient nie są zależni od siebie (lub nie wiedzą o sobie).

Źródło

2016-01-15 23:13:13 jcfolsom

Korzystanie DAOs z kompozytowych Objects

Odpowiedz

Powiązane problemy