Ahoj, > jasne, takze je mensi bolest zobrazit null, nez se dozvedet, ze je neco > spatne, aha ...
Muze se to zdat divny, ale kdyz se na to podivate z uzivatelskeho hlediska... Co je pro Vas lepsi, kdyz v pravem hornim rohu neuvidite svoje prihlasovaci jmeno, pripadne dole na strance diskusi k uverejnenemu clanku (coz jsou veci, ktere se napriklad diky chybe aplikace do DTO neprenesly), nebo kdyz se Vam misto cele stranky zobrazi error stranka? Sance je, ze si uzivatel chybejici infomace ani nevsimne (vemte si kolik se toho dnes na strankach zobrazuje). Pokud si vsimne, reportuje to jako standardni bug, nicmene aplikaci muze normalne nadale vesele pouzivat. To se neda rici o stavu, kdy se na urcitou stranku vubec nedostane, coz pak musite resit prioritne ve stresu. Pri pouziti JSP/EL se misto null zobrazuji maximalne prazdne retezce, takze hloupe vypadajici "null" na GUI stejne nikde neuvidite. Ja osobne preferuji prvni moznost, tj. nezobrazit data pokud nejsou k dispozici, protoze stranka muze byt pouzitelna i bez nich. Kdyz se neco nezobrazi, je to typicky bug prio max 2 a mate cas a klid to fixovat, kdyz uzivateli stranka pada s chybou, je to typicky bug prio 1. Z hlediska programatora a testu je urcite lepsi nechat probublat vyjimku, ale to neplati o uzivatelich. Ale nase nazory se mohou ruznit, ja zcela akceptuji Vas nazor :) > Co testy ?? Pokud mas napr. integracni testy v seleniu, pak ti testy spadnou > a z vyjimky hned vis co je spatne ... a deje se to automaticky ... Jak jsem tusim psal, aplikaci vyvijim sam a testy pisu maximalne na urovni unit testu komponent, nikoli na urovni automatickeho proklikavani GUI. I kdybych nadherne mel auto-proklikavaci GUI testy, kolikrat se Vam stalo, ze jste v nich nejaky case nezohlednil a ten se pak objevil az v produkci a kvuli nemu se musela aplikace narychlo fixovat? Ale dostali jsme se uplne jinam, nechci obhajovat DTO a hanit vas pristup se session.initialize(), ale spise se ve vlastni aplikaci zbavit obou :-) > Jo to je docela pekne reseni ... otazka je, zda budete schopen vytvorit > sessionu s release-after-statement=true, protoze se ukazuje, ze se to > dava do SessionFactory pres Setting, a tim "znicite" SessionFactory. Mozna by > slo mit 2 SessionFactory, jednu pro view (bude mit > release-after-statement=true) a druhou na provadeni business logiky. Presne to zamyslim. > To je zase jina pohadka, tu si nechma na priste :-) V souvislosti s timto bych Vam mohl povedet mnoho veselych historek z vyvoje a spravy aplikaci pro jobs.cz/prace.cz (> 1000 db transakci za sekundu v castech Muj i Nas, ted po reklamnich kampanich nejspise vice), ale to nekdy priste a hlavne v jinem threadu :-) Honza -----Původní zpráva----- Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za uživatele Jiri Mares Odesláno: Tuesday, June 12, 2007 13:31 Komu: Java Předmět: Re: Hibernate aneb jak se (ne)vyhnout DTO Ahoj, >> Neni mi jasne jaky je rozdil v pouziti DTO vs inicializace, pokud to >> kopirujete z business modelu do DTO, >> tak proste jenom misto kopirovani provadejte inicializaci ...??? > > To ano, ale kdyz mam DTO, tak nehrozi LazyInitializationException. S > touto vyjimkou si view "poradi" tak, ze uzivatel skonci na error > strance a smytec a vy musite aplikaci urychlene fixovat a pak > zdlouhave znovu testovat, nasazovat apod. Momentalne nejsem v situaci, > kdy bych chtel venovat moc casu opakovanemu testovani, ci psani a > udrzovani testovacich casu (jsem na tu aplikaci sam :). Cili v tomto > smyslu pokladam DTO za robustnejsi reseni. jasne, takze je mensi bolest zobrazit null, nez se dozvedet, ze je neco spatne, aha ... >> Samozrejme se to da resit selektivne (asi ne u portalu), ale u >> normalni aplikace vim, cca. jaka view budou nasledovat >> a pak jsem schopen rici, ze u view, kdy se pouze generuje vystup neni >> problem nechat otevrenou read-only transakci >> a pockat az se to vygeneruje. U jinych muzu business model nainicializovat a >> zavrit transakci, tj. zadne dalsi dotahovani z db. > > Moc pracny IMO. View se ruzne upravuje a sledovat co se z nej vola a > jak se co taha je u slozitejsich aplikaci nad moje sily. Co testy ?? Pokud mas napr. integracni testy v seleniu, pak ti testy spadnou a z vyjimky hned vis co je spatne ... a deje se to automaticky ... >> To bude priserne pomale ... chytat vyjimky, asociaovat objekty s >> novymi sessionami a pak je dotahavat ... > > Proc myslite? Vytoreni nove session by melo byt celkem jednoduche, je > to koneckoncu jenom takovy wrapper nad db spojenim. Alokace db spojeni > z poolu taky nic tragickeho. Asociace objektu se session taky nic moc > nedela, vyprazdneni session a jeji uzavreni s tim, ze se nic neuklada > by mela byt taky jednoducha operace. Jediny co muze trvat nejdele je > vlastni db dotaz a to uz je celkem jedno, zda ho delam v nove session, > nebo ve stavajici session. Jde typicky o nekolik jednotek az desitek > takovychto volani na stranku (seznam kontaktu k uzivateli, seznam > firemnich nastaveni apod). Pokud by se mely tahat nejake dlouhe > seznamy, tak samozrejme radeji pouziji nejake DTO naplneny jednim > dotazem a Hibernate ani nepouziju. No jde o to kolik takovych vyjimek za dobu vytvoreni view bude, protoze vyhozeni vyjimky vcetne stacktracu neni "levna" zalezitost, to uz mozna bude jednodussi tam namontovat nejakej interceptor, ktery by poznal, ze se snazite neco dotahnout a tam vcas zasahnout ... pokud to jde > Misto chytani vyjimek zkusim AOP interceptor nad get* metodama > domenovych objektu s tim, ze pokud interceptor zjisti, ze je getter > volany mimo JPA transakcni kontext (tj. mimo kontext, kde se mi vazby > dotahuji sami) a objekt vraceny z prislusneho getteru je proxy ci > proxy kolekce, tak otevru (pokud neexistuje) novou Hibernate session > (flush=never, release after statement=true) a dany objekt objekt > automaticky dotahnu a vratim. > > Vyhody: naprosto transparentni reseni z pohledu view, db spojeni > alokovano jen na nezbytne nutnou dobu > Nevyhody: drobny cpu overhead proti rucnimu volani session.initialize() Jo to je docela pekne reseni ... otazka je, zda budete schopen vytvorit sessionu s release-after-statement=true, protoze se ukazuje, ze se to dava do SessionFactory pres Setting, a tim "znicite" SessionFactory. Mozna by slo mit 2 SessionFactory, jednu pro view (bude mit release-after-statement=true) a druhou na provadeni business logiky. > Nezapomente, ze bottleneck byva typicky db, nikoli cpu. Kdyz se mi > nebude dostavat cpu pridam dalsi cpu, ci rovnou novy stroje do > klusteru. Investice radove desitky tisic. Kdyz nebude stihat db, mam > problem (neni bohuzel moc pravidlem, ze db je mozny jednoduse > klusterovat - maximalne tak funguje failover, ale rozlozeni zateze na > vice db stroju se synchronni replikaci dat je dost problem). To je zase jina pohadka, tu si nechma na priste :-) Jirka > -----Původní zpráva----- > Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za > uživatele Jiri Mares > Odesláno: Tuesday, June 12, 2007 11:47 > Komu: Java > Předmět: Re: Hibernate aneb jak se (ne)vyhnout DTO > > > > Ahoj, > >> Tu inicializaci asociaci pred commitem jsem taky delal, ale clovek i >> presto, na muj vkus prilis casto, resi LazyInitializationException >> diky tomu, ze se metoda vola z ruznych kontextu, kde jsou potreba >> ruzna data (takze tokonci tak, ze clovek pridava dalsi a dalsi >> session.initialize()). Neprijemny side-efekt je pak i to, ze se nekde >> dotahuji data, ktera by se v danem kontextu dotahovat vubec nemusela. >> Tohle mi prijde neuhlidatelne, proto jsem (doufam ze jen) docasne >> zvolil cestu DTO a to i za cenu zvysene pracnosti. > > Neni mi jasne jaky je rozdil v pouziti DTO vs inicializace, pokud to > kopirujete z business modelu do DTO, tak proste jenom misto kopirovani > provadejte inicializaci ...??? > > > >> Myslenka s dvema transakcema per session me pred casem taky napadla, >> nebo jsem to mozna nekde cetl. Akorat me dost desi, ze db spojeni >> zustane alokovano po celou dobu renderovani view, coz je vec, kterou >> ovlivni i rychlost spojeni klienta (pokud mi 100 lidi posle request na >> aplikaci a nebudou pak cist response, nebo jen velmi pomalu a dojde na >> strane serveru z zaplneni bufferu, budu mit v aplikaci razem blokovano >> 100 spojeni). Tuto vlastnost ma samozrejme i to reseni se dvema >> session. > > Samozrejme se to da resit selektivne (asi ne u portalu), ale u > normalni aplikace vim, cca. jaka view budou nasledovat a pak jsem > schopen rici, ze u view, kdy se pouze generuje vystup neni problem > nechat otevrenou read-only transakci a pockat az se to vygeneruje. U > jinych muzu business model nainicializovat a zavrit transakci, tj. > zadne dalsi dotahovani z db. > >> Z meho pohledu idealni reseni by byl nejaky interceptor na >> LazyInitializationException, ktery by dostal referenci na >> problematicky objekt, otevrel by session, dotahl by co potrebuje, >> session zase rychle zavrel a uvolnil tim alokovane db spojeni. Ale >> toto se obavam neni Hibernate podporovano, ale zase nejsem takovy >> Hibernate guru. Kazdopadne tuto moznost aktualne zkoumam. > > To bude priserne pomale ... chytat vyjimky, asociaovat objekty s > novymi sessionami a pak je dotahavat ... > > Nevim, asi mam jednoduchy business model, ale dotahnout vse potrebne > dopredu mi zatim nedele problemy. Nelibi se mi, a proto to zkusim > zmenit ... > > Jirka > >> -----Původní zpráva----- >> Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za >> uživatele Jiri Mares >> Odesláno: Tuesday, June 12, 2007 10:12 >> Komu: Java >> Předmět: Re: Hibernate aneb jak se (ne)vyhnout DTO >> >> resim podobny problem, lepe receno kdo ne .... >> >> Ja jsem na to zatim sel tak, ze vim, co view potrebuje a tyto >> asociace, ci lazy dotahavane property nainicializuji pred commitem >> transakce, tj. dotahnu do business objektu vse, co bude potreba pro >> zobrazeni >> >> Druha vec o ktere jsem premyslel a jsem rozhodnut ji udelat je >> pracovat s jednou sessionou, ale 2 ma transakcema. Tj. provedu zmeny a >> commitnu transakci, nasledne otevru dalsi v te same sessione, ale udelam ji >> read-only, aby se v ni nedaly delat zmeny a jenom se dotahavalo, pak vlastne >> nic nezamyka (mam to tak udela v DB diky spravnemu isolation >> levelu) a muze klidne trvat i par sekund. >> >> Jinak DTO neni navrhovy vzor ale obycejny workaround ... >> >> Jirka >> >>> 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. > -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic
