A możesz szerzej opisać problem? Na konkretnym przykładzie?
Odpowiadając generalnie - na warstwach obiektów domenowych, ale nie fasady, w twoim przypadku pewnie będzie to serwis. Możesz także tworzyć te obiekty w encjach jeżeli to co chcesz otrzymać jako obiekt B to value object.
Class Member {
String name;
String surname;
}
Class Relation. {
Member Father;
Member Mother;
List<Member> Children;
Relation(Member mother, Member father, Member... child) {
}
W chwili gdy tworze member powinna sie stworzyc. takze Relation(null, null, createdMember).
W starej implementacji, logika ta byla po stornie Service bo jest transakcyjny.. wiec nawet to logiczne.. jesli pojawi sie blad przy zapisywaniu relacji to member tez powinien sie wykasowac. Fasada natomiast realizowala tlumaczenie i sprawdzala ewentualnie na wejsciu nulle. Ale nie jestem pewna czy to podejście jest prawidłowe. Czy może Fasada, która zarzadza tymi DTO powinna sobie decydowac o tym jakie obiekty tworzy i przesyłać to do serwizu, który zajmuje się jedynie wywoływaniem odpowiednich funkcji z repozytorium.
Kazde Repozytorium, ma odpowiadający mu Serwis. Natomiast Fasady mam tylko 2. Jedną dla Usera i typowo spraw zarzadzania kontem i drugą dla Projektu. I w projekcie wstrzykuje beany wszysktich potrzebnych serwisów.
Potem dochodzi temat zwracancych obiektów. Jako że dodanie jednej relacji może powodowac ze kilka trzeba będzie zmodyfikowac.. jeszcze inne usunąc itd... to zwracanym DTO będzie raczej całe Familly. Dlatego wlasnie pomysł mój był aby to fasada zarządzała, a serwisy robiły tylko to co im się kaze.
Ogólnie mam tez poboczny problem a mianowicie bledy noSession przy Fetch.LAZY czy to możliwe ze dlatego, ze wlasnie transakcja się zakonczyła gdy Service zwraca obiekty do trannsformacji w DTO na warstwie Fasade??