[Java lista] j2ee persistence layer tervezesi megfontolasok

[Istvan Bencze]

Sziasztok!

Néhány hónapja bennem is pontosan ugyanezek a kérdések merültek fel,
gondolom, aki elkezd ismerkedni a GWT-vel, egy idő után hasonló élményei
támadnak! Én igazából három útat találtam:

1. Ez a Transfer Object-es, View Helper-es irány, ahol pl. Dozer-t
használhatsz az átforgatásra.
2. Gilead avagy régi nevén Hibernate4GWT, ez segít kivinni ezeket az
objektumokat GWT oldalra minden gond nélkül. Hátránya, h. nem biztos, hogy
pontosan tudod, hogy mi megy ki, és mivel terheled a hálózatot feleslegesen.
3. Függetleníted magad a GWT-től, XML vagy JSON alapú interfészeket csinálsz
a szerver oldal és a kliens oldal között, így ha váltani szeretnél
fájdalommentesebb, és a GWT is támogatja ezeket.

Én az utolsót választottam volna, de időhiány miatt az első mellett
döntöttem. Kb. 15 perc volt megoldani, és nincs is vele problémám, viszont
van egy két-dolog, ami eléggé zavar:

   - A view helper POJO-im szinte tök ugyanazok, mint az annotált JPA-s
   POJO-im, ha változik valahol, akkor két helyen kell kalapálni. A Dozer-t nem
   nagyon kell konfigurálgatni, mert ha ugyanaz a neve a két POJO-ban a két
   mezőnek, akkor meg tudja oldani simán.
   - Milyen rétegben oldom meg a JPA-s objektumok viewhelperekké alakítását?
   Csináljak controllert? A service-eim had ne tudjanak már, hogy milyen kliens
   van előtte! Automatikus JPA POJO -> viewhelper transzformáló réteg/gwt
   controller? Ahhoz persze, hogy a viewhelperré alakítás gond nélkül
   megtörténjen, ugye figyelni kell, hogy a lazy fieldeket is ki tudja szedni a
   dozer, vagy marad a eager fetch.

Egyébként igazából szerintem nagyon hasonlít a szituáció a sima webes
környezethez.



Steve

2009/4/30 István Viczián <viczian.istvan at gmail.com>

> Üdv,
>
> így van, a Traansfer Object és a View Helper Java EE tervezési minta a
> te barátaid. Ha rákeresel a weben, akkor rengeteg példát találsz.
>
> Viczi
>
> 2009/4/30 Böszörményi Péter <zmblevlist at gmail.com>:
> > On Thu, 30 Apr 2009 08:52:08 +0200, zamek <zamek at vili.pmmf.hu> wrote:
> >
> >> hello,
> >>
> >> Egy gwt munka kapcsan kerult felszinre a problema, de valoszinuleg
> >> tobbunknek
> >> volt/van gondja vele.
> >>
> >> Ajanlas: Feluleteket (interface) tervezzunk, ne osztalyokat.
> >>
> >> A perzisztencia domain-eket elobb-utobb a megjelenitesi retegbe is at
> >> kell
> >> vinni. Ezzel az a baj, hogy:
> >>
> >> 1. nem lehetnek interface-ek, mert azokat nem lehet serializalni
> > Interfacet nem is, de az ot implementalo osztalyt valoszinuleg igen.
> > Persze ettol fuggetlenul a domain objektumokat bedugni interfacek moge
> > marha kenyelmetlen, szerintem felesleges is.
> >
> >>
> >> 2. ha egyszeru java bean-ek, akkor a megjelenitesi reteg hozzafer olyan
> >> adatokhoz, amihez semmi koze. A gwt kapcsan meg nagyobb a problema,
> >> mivel a
> >> gwt compiler nem tudja leforditani az annotation osztalyokat.
> > Ha nem lehet elmagyarazni a gwt-nek, h skippelje az annotaciokat, esetleg
> > meg lehet probalni xml mappingel leirni az egeszet.
> > Azt viszont nem nagyon ertem, hogy a reteg hozzafer olyan adatokhoz,
> > amihez semmi koze. Ha nem erzekenyek az adatok, akkor viewban nem kered
> el
> > a beantol az adatot, es nem lesz utban. Ha meg erzekeny, es jogosultas
> > fuggo, akkor mar az elkeres pillanataban ellenorizni kell, hogy
> jogosult-e
> > az adott adatokhoz.
> >
> >>
> >> 3. ha a perzisztenciat kulon jar-ba teszem, az annotation-ok miatt a
> >> hivatkozott jar-ok szama tobb Mb-ra rug, ami teljesen felesleges. Persze
> >> ez
> >> csak akkor gond, ha a megjelenitesi reteg nem az appserverben fut (gwt,
> >> application client sw).
> > Nem szukszeges, hogy a cp-ben benne legyenek az annotaciok. Ha a jvm nem
> > talalja a hivatkozott annotaciot, akkor ugy veszi, mintha nem is lenne
> > rajta.
> >
> >>
> >> A serialization problema miatt a perzisztencia domain-ek nem lehetnek
> >> interface-ek, sem abstract osztalyok.
> > A megvalosito objektum lehet, es ti ugyis azokkal dolgoztok.
> >
> >>
> >> Mi a celszeru megoldas?
> >>
> >> 1. a perzisztenciaban egyszeru java bean-ek, annotation nelkul, majd a
> >> konkret
> >> ejb megvalositasban leszarmaztatott osztaly, amiben mar benne vannak az
> >> annotation-ok, valamint a privat reszek.
> >>
> >> 2. perzisztenciaban egy wrapper osztaly, aminek van egy getter/setter-e
> >> ami a domain interface tagra vonatkozik.
> >>
> >> vagy milyen egyeb megoldasokat szoktatok hasznalni?
> >>
> > Szerintem teljesen hetkoznap value objectek megfelelnek a celnak. Arra
> > erdemes oda figyelni, h a felhasznalashoz optimalis legyen. Pl nem baj,
> ha
> > a egy forum topik listajanal feleslegesen nem utazik mindegyik topik
> > osszes hozzaszolasa.
> >
> >
> > --
> > Üdvözlettel,
> > Böszörményi Péter
> > _______________________________________________
> > Javalist mailing list
> > Javalist at javagrund.hu
> > http://javagrund.hu/mailman/listinfo/javalist
> >
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20090430/e86da6de/attachment.html