2006/08/28

JavaBeans és O/R mapping

Ülök az ablak mellet és a tájat nézem. A JavaBeans-eken elmélkedem.

Egy kevéssé típusos nyelvben olyat is láttunk már hogy lekérdezés előtt az sql query-t keresztül eregették néhány kiterjesztő modulon valamilyen hook rendszer segítségével, és mindegyik modul átformálta úgy a lekérdezést, ahogy ő szerette volna (pl. hozzácsapott valamit). A választ meg majd szintén keresztül eregették a hook systemen, és minden modul szemezgetett 
belőle, és felhasználta az eredményben a kapott plusz mezőket.

Ez eddig nem nagy szám. Javaban is meg lehet ezt csinálni. Mondjuk én szívem szerint kipróbálnám, hogy nem a query String referenciáját küldeném át (ez a String viselkedése miatt nem is lenne annyira jó) hanem csinálnék egy Query osztályt, amihez tagfüggvényekkel tudnék hozzáadni plusz WHERE, ORDER BY stb. feltételeket.

Aztán megkapnám az eredményt. Ez is száll ágról ágra, és minden modul ki tudná venni pl. res.getString("plusz mező")-vel plusz oszlopokat a ResultSet-ből, amiket az sql módosításával ő biztosított magának.

A probléma ott van, hogy múltkor elkezdtem O/R mapping-gel kísérletezni, és az első egyszerű példák valóban nagyon kellemesen kézbe símultak. Csakhogy O/R mapping-gel az adatbázis válasz struktúráját beledrótozzuk a bean osztály szerkezetébe, amit nem fogunk tudni sehogy sem kiterjeszteni (a leszármaztatás már rögtön a több modulnál elvérzik, de az interface implementálás sem járható út).

Őszintén szólva nem ismerem ilyen mélyen az O/R mapping megoldásokat, hogy erre milyen megoldásokat ismer. Két dolog kéne
  • egyrészt, hogy a lekérdezéskor ki lehessen terjeszteni az (?)SQL lekérést plusz WHERE, JOIN stb. feltételekkel
  • és az így kapott plusz mezőket valahol visszaadja
Pl. visszaadhatna egy bean helyett egy bean tömböt (legyen mondjuk Map). A tömb elemeiért (amik egyenkén JavaBean-ek) különböző modulok felelősek, és az alapmodulnak nem kell tudnia a kiterjesztés plusz bean fragmentumairól. Csak persze akkor meg az lesz a kérdés, hogy honnan 
tudjuk, hogy a lekérdezésnek az egyes oszlopaiból melyiket melyik JavaBean-be dobjuk szét.

Nem tudom sikerült-e jól artikulálnom a problémát, de szerintem elég szerény kívánalom. Talán tudja is valamelyik O/R mapping cucc, csak sokkal mélyebben el kéne olvasni a doksikat.

8 megjegyzés:

Kocka írta...

Hat, amennyiben jol ertem hogy mire gondolsz akkor nezd meg a hibernate-ben a filtereknek, azokkal lehet plusz where felteteleket hozzaadni az egesz sessionodhoz.

Nem teljesen ertem hogy miert adnal hozza peldaul uj mezok lekerdezeset, visszakapsz egy bean-t, abban van minden adat amit a kerdeses bean-hoz tartozik, ha masik bean kell, akkor masik lekerdezes. A teljesitmeny miatt aggodj kesobb, legfeljebb bekapcsolod a cache-t :)

elek írta...

Hát konkrétan csak PHP-val pontosabban Drupallal tudok példálózni. Ott úgy van, hogy van egy alap funkcionalitást tudó tartalom modul. És lehet csinálni olyan modulokat, hogy ezt az alap modult különböző hook-okon keresztül kibővítse.

Pl. minden tartalomhoz egy értékelést (10-es skála) szeretnék fűzni. Ehhez egy külön táblát csinálnék, a lekérdező query-t átírom (hookÖ, hogy join-olja hozzá az én táblámat is, és a megjelenésbe kicsit belepiszkálok, hogy a plusz lekérdezett mezőmet is megmutassa (gyakorlatban a megjelenés is elintézhető hook-on keresztül).

Úgy látom, hogy azok akikik Javaban gondolkoznak, azok teljesen máshonnan közelítik meg a dolgot. Pl. van egy J2EE alkalmazásunk, és ha egy plussz értékelést akarok, akkor kibővítem az EJB-ket, meg a db-t, és csókolom.

Ami nekem nagyon hiányzik, az a teljesen moduláris megközelítés. Az Eclipse és a Netbeans GUI-ja (amennyire rálátok) nagyon jó modularitással bírnak, de weben még nem láttam hasonlót. O/R mappingben meg pláne.

Kocka írta...

hat, ez az igeny nekem kicsit ugy tunik hogy egy masik komponens hatokorebe akarsz belenyulni, akkor lehet hogy erdemesebb az adott komponensbol egy sajatot leszarmaztatni ami kiboviti az elozo tudasat a neked szukseges callbackekkel vagy konkretan azt a tudast beleirod amit hianyolsz.

En EJB-kkel nem baratkozom :)

elek írta...

Mondjuk ugy, hogy az egyik komponensem felajanlja masoknak, hogy bizonzos helyeken bele tudjanak nyulni a hatokorebe. Es masok pedig ki tudjak terjeszteni a tudasat a komponensemnek. Epp az a lenyeg, hogy nem en akarok leszarmaztatni, hanem masoknak megadni a lehetoseget, hogy kiterjesszek a modulomat. Amig csak egy ilyen mas van, akkor lehet, hogy leszarmaztatas is menne, de en azt szeretnem, hogy egyszerre tobb fele is kibovitheto legyen a komponensem, ket teljesen eltero funkcioval. Ezt mar szvsz nem tudnak megoldani leszarmaztatassal.

Kocka írta...

Szoval ha jol ertem amikor az adatbazisba modosit barmilyen tartalmat egy komponensed, akkor te szeretned ha az ahhoz a rekordhoz tartozo statisztika is modosulna. Egyszeruen kivitelezheto, peldaul ha hibernate-specifikus kornyezetben gondolkudunk akkor erre valoak az interceptorok (ami egyfajta callback), vagy pl ha egy JDBC-s DAO-d van akkor tehetsz ele egy AOP-os interceptort. Es ezeket az objektumokat adhatjak siman a tobbi komponenseid.

Gondolom en, pedig a konkret problemara nincs sok ralatasom :-D

elek írta...

Hát az AOP-val meg nekem adtad fel a labdát. Lehet, hogy az segítene.

Egyébként nem is annyira konkrét probléma van, mint inkább elméleti tervezgetés. Valamikor a következő hetekben úgy is nekem fog jönni egy kis UML, lehet, hogy akkor majd diagramokkal megpróbálom a problémát jobban artikulálni.

Elsősorban nem abban gondolkozom, hogy én vagyok a fejlesztő és a megrendelőnek csinálok valamit, hanem hogy ha írok mondjuk egy CMS-t, akkor hogy tudok olyan kapcsolódási pontokat nyújtani, hogy külső programozók modulokat tudjanak írni a rendszerembe, ami esetleg egyes meglévő funkciók viselkedését is módosítják.

Mondjuk egy másik kitalált példa:

Zseniális CMS programom mondjuk kezelné a felhasználókat, a belépéseket és mondjuk mindenkinek lenne profile oldala. Valaki szeretné használni a programomat, de úgy hogy a profile oldalon skype azonosítot is meg lehessen adni. Ezt úgy szeretné elérni, hogy nem módosí a portál kódjában, csak plusz modulokat (mondjuk egy jar-ba csomagolva) tesz valahová.

Valami ilyesmi

Kocka írta...

Hat igen, ha valami egeszen brutalisat akarsz tervezni akkor ahhoz kell egy kemeny problema-felmeres, analizis. Szerintem ilyenkor erdemes korbenezni az open source implementaciokban, CMS eseteben pl a lenya, legrosszabb esetben is tanul belole egy csomot az ember.

elek írta...

Ja nézeteggetem, de nem találtam még semmi idevágót. A Java Plugin Framework-ről állítottáak, hogy jó ilyenre, de nem találtam semmi kézzelfoghatót.

A Spring 2-vel kapcsolatban beszéltek OSGi-ről, az lehet, hogy pont az lenne, amit keresek, (mem amúgy is Spring, tehát elfogult lennék), de még nem találtam semmi konkrétumot róla...