[siemanko]

Potrzebuję porady. Staram się w każdym moim projekcie wdrażać jakieś wzorce i działać zgodnie ze sztuką. Ale co rusz trafiam na z pozoru trywialny problem i mam blokadę. Taki sam problem mam ze wzorcem repozytorium. Niby prosty i łatwy w implementacji. Jednak z tego co rozumiem, każde repozytorium obsługuje jeden typ obiektów. Co zrobić w przypadku kiedy chcę wyciągnąć z bazy dwa typy obiektów za jednym zapytaniem z join? Przykładowo, mam ConsumptionRepository który pierwotnie zwraca obiekt:

Consumption
- consumptionId
- productId
- size
- date
- itp

Jednak ja potrzebuję również obiektu Product, który jest z nim powiązany za pomocą id. Mogę wykonać kolejne zapytanie tym razem do ProductRepository po posiadanym już productId, ale jest to znowu kolejne zapytanie, gdzie mogę bez problemu wykonać bardziej optymalnego joina.

#programowanie #java #wzorceprojektowe #cleanarchitecture #unclebob

[siemanko]

Czy dopuszczalne jest coś takiego?:

void loadWithProduct(int consumptionId, Callback callback);

interface Callback {
void onLoaded(Consumption consumption, Product product);
}

[nie_jem_grzybow]

@siemanko: A korzystasz z JPA?

[siemanko]

@nie_jem_grzybow: Ogólnie do bazy używam biblioteki ORMLite.

[nie_jem_grzybow]

@siemanko: No, czyli wspiera raczej JPA, więc jak chcesz, żeby wszystko było zgodnie z korpostandardami powinieneś wszystkie wiązania utworzyć w klasach @Entity i wtedy pobierając jeden typ obiektu możesz pobierać (najlepiej LAZY) połączone z nim listy obiektów/obiekty.

[siemanko]

@nie_jem_grzybow: Dzięki za wyjaśnienia. Tylko proszę wyjaśnij mi jak to właściwie ma rozwiązać mój problem?
Czy taka encja z wiązaniem do innej listy obiektów nie wykonuje dodatkowego zapytania (zwłaszcza LAZY)?
I czy repozytorium wtedy nie ma racji bytu?

[nie_jem_grzybow]

@siemanko: Wykonuje zapytanie, ale innego sposobu nie ma, bo gdzieś tego joina przecież musisz zrobić - co więcej przy lazy fetch w JPA pobranie wiązanych obiektów może być wykonane np. dopiero w obiekcie serwisowym (tylko w tej samej transakcji...) dzięki czemu repo pozostaje czyste od innych obiektów tak naprawdę.
A w repo (czyli lepiej zaprojektowanym DAO a niekoniecznie tylko CRUD) oczywiście mogą znajdować się funkcje filtrujące wyniki po składowej encji (też