Zdravim, No jo, ale takto jednoduse to funguje jen u jednodusich datovych modelu. Co kdyz Address obsahuje reference na dalsi entity napriklad GisEntity representujici jednotlive prvky adresy (teritorium, zeme,...). Pak bych musel psat findery uplne na vsechno, coz je to, cemu bych se chtel nejakym inteligentnim on-demand loadingem vyhnout. Hibernate ho sice ma, ale funguje s temi omezenimi o kterych jsem psal (bud pouzijete open session in view, nebo DTO), pricemz oboji ma sve nevyhody.
OSIV s tou volbou "realese after statement" zni ale celkem zajimave a odstranilo by to problem s dlouhym drzenim db spojeni. Honza -----Původní zpráva----- Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za uživatele Ondøej Fafejta Odesláno: Tuesday, June 12, 2007 12:28 Komu: Java Předmět: Re: Hibernate aneb jak se (ne)vyhnout DTO 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 >
