Zdravím! Nepoužívám hibernate, ale v JPA to řeším takto.
při načítání entit v DAO používám Constructor Expressions in the SELECT Clause Tedy načítám pouze data, která potřebuji zobrazit - přímo do entity. Pokud potřebuji zobrazit podřízené entity, vytvořím si pro to v DAO metodu, která mi najde podřízené entity. např. 1. metoda pro vyhledání všech zaměstnanců obsahuje PQL SELECT new Employee(res.id, res.surname, ...) FROM Employee res 2. když potřebuju zobrazit seznam adres k zaměstnanci, tak si vytvořím druhou metodu v DAO - List<Address> findAddressesByEmployeeId(long id); Nevýhoda je, že vzniká v DAO spoustu metod navíc. Výhody: - načítají se pouze data, která se mají zobrazit - při vyhledávání podřízených entit se může uplatnit strákování, třídění, filtrování podle různých kritérií. fafi Jan Moravec napsal(a): > Zdravim, > > Mam obecny problem s pouzivanim ORM frameworku u webovych aplikaci, ktery se > mi nedari uspokojive vyresit. Kdyz jsem si ted precetl clanek Dagiho o DTO na > java.cz a o tom, jak je to opomijeny vzor, pripomelo mi to muj boj s DTO. > > Pouzivam Hibernate a puvodne jsem si (naivne) myslel, ze zivot bude sladky, > ze Hibernate domenove objekty budu vracet do view a to mi z nich bude cist a > zbavim se nutnosti psat DTO tridy. To jsem si myslel do doby, nez jsem poprve > uvidel vyjimky s hlaskou "Session is closed". Duvod vyjimky je zcela > pochopitelny, protoze Hibernate session (dale jen HS) mi managuje JTA, takze > ve view je session jiz uzavrena a kdyz se view pokousi dotahnout nejakou lazy > asociaci, vyhodi zminovanou vyjimku. > > Managovat HS v nejakem filtru ve view vrstve mi prijde nepouzitelne pro vetsi > aplikace s ohledem na to, ze view muze provadet dost dlouhe akce, napriklad > volat web-service, provadet nejaky casove slozitejsi vypocet apod. Mangovani > HS ve filtru (tzv. open-session-in-view pattern) by tedy znamenalo: > > 1) HS a potazmo db spojeni budou alokovany na dlouhou dobu (sekundy az > desitky sekund) -> vycerpani spojeni pri vetsi zatezi aplikace, nektere > stranky/akce view treba s db vubec nepracuji, tak proc vytvaret HS a alokovat > db spojeni > > 2) Pri otevreni HS bude db spojeni dlouho viset v necommitnutem stavu > (vlastne po celou dobu renderovani view) -> vyskyt locku/deadlocku v db. > > Jak z toho ven? > > Momentalne resim tak, ze pro domenove objekty Hibernate pisu DTO objekty a > skripu zubama (dvakrat pisu to same, zmeny v domenovych objektech se musi > propagovat do DTO, nutnost rucne "presypavat" data mezi domenovymi objekty a > DTO). Zkratka z DTO patternu nejsem nijak zvlast unesen, alespon ne v tomto > kontextu. Napadlo me pouzivat 2 session, ale to jsem nikde nevidel v akci a > taky to nemam jeste uplne promyslene: > > 1) lazy alokovana session, ktere je striktne read-only a je managovana ve view > 2) standardni "vykona" session managovana pres JTA > > Pak je potreba jen nejak automaticky zajistit (napr. pres nejaky JTA > interceptor), ze domenove objekty Hibernate predavane do view se sami > asociuji s tou read-only session a bude tedy mozne se vyhnout DTO patternu > pro praci s domenovymi daty a pomoci te read-only session dotahovat i lazy > asociace dle potreb view. > > Nepouzivate toto nekdo? > > Diky, > Honza >
