- This topic has 41 hozzászólás, 5 résztvevő, and was last updated 6 years, 1 month telt el by
.
- Bejegyzés
Ok, lassan lehet, hogy kezdek megérteni részeket.1 - Az egyedi kereső műveleteimet meg kell írnom. Ez igaz. Azonban sokféle tábla van sokféle szerkezettel. Mindhez megírhatom az egyedi műveleteket, de az oo nem erről szól. A kereső műveletek nagyon kevésben térnek el egymástól, emiatt minél kevesebbszer szeretném megírni azokat.2 - Azt látom én is, hogy a rekord keres magában nem jó. Szerinted egy kereső objektum kell, én meg statikus műveletre gondoltam. Elméleti szempontból nem értem, miért nem lehet statikus művelet. Főleg azért, mert javaban elég sok statikus factory művelettel találkozom, ahol van egy külön osztály, ami objektumokat gyárt. Így nekem nem volt idegen, hogy statikus műveletben gondolkodjam. S ha már statikus, miért ne lehetne az osztály saját művelete. Az egyéb factory műveletekről azt állítják, azért kell külön osztályban lenniük, mert a generált objektum más-más osztályba is tartozhat. Nálam azonban egy ilyen művelet mindig csak egy osztály példányát generálná, tehát emiatt akár az osztály művelete is lehetne.Jelenleg is működnek az aktív rekordjaim, csak szép, elmélethez illő megoldást keresek, éppen a későbbi problémák elkerülésére. Jelenleg sok művelet sokszor meg van írva, minden adattáblához külön-külön. Ez így rém csúnya, de használni már könnyű.Talán a kérdésem egyetlen gondolatban is összefoglalható: miért nincs statikus öröklődés? Ez elméleti korlát, vagy csak a java nyelv korlátja?
1) A oo programozás legfőbb ismérve pont az egymással kapcsolatban álló programegységek hierarchikus elrendőzédése.Pont az amiről beszéltem.2) Bizony nem jó. Lehet keresőobjektum, de egyik legcélszerűbb megoldás abba az osztályba belerakni, amely a rekordokat keresi... pontosabban, - mivel oo-ságról beszélünk - abból származtatott osztályba, ami megörökli a már előre definiált értékeket.További előnye, hogy ez az osztály fog tudni mindent a rekordokról, hisz pont az ő adatterületén helyezkednek el.Mármint mire gondolsz a satikus öröklődés esetén?A leszármaztatott osztályban öröklődő származtató osztályban lévő statikus objektumokra?Mert akkor - természetesen - örökölhető, csak nyilván egy darab lesz belőle, mivel statikus.Egyébként a resultset tartalmához egyenként is hozzá lehet férni, akár név szerint is. Ez egy kicsit jobban hasonlít az sql utasításokhoz.Pl. töltsünk be csak két oszlopot és frissítsük az első sor name és age nevű oszlopát:
Code:ResultSet rs = sm.executeQuery("SELECT name, age FROM REGISTRATION");rs.absolute(1);rs.updateString("name", "Pityuka");rs.updateInt("age", 10);Szerintem ez is csodásan átlátható. (Persze, mert itt - gondolom költségígényesebb - írásról van szó, a rs-nek frissíthetőnek kell lennie: ResultSet.CONCUR_UPDATABLE paraméter.)
A tárolók nagyon dinamikusak, ezért sokmindenre ráhúzhatók, és nekem épp ezért nem kényelmes a használatuk.A ResultSet egy jó megoldás, csak épp fordítási időben nem tudja ellenőrizni az adatszerkezetet, amire az aktív rekord képes.Statikus öröklődésen azt értem, hogy egy osztály statikus műveletét egy leszármazott osztály statikus művelete felülírhassa.
(A rekord egy lineáris, direkt hozzáférésű adat szerkezet… így nem ellenőriz semmilyen adatszerkezetet.)Megint másik kérdés, hogy a komolyabb oo szerkezetekben nem használnak direkt hozzáférésű szerkezeteket, inkább függvényekkel oldják meg a hozzáférést, így pl. könnyebben szabályozható, hogy az adat írható, olvasható legyen-e.Egyébként mi az amire egy osztály nem képes és egy "rekord" (puszta adathalmaz) képes? Nem igazán értem...Művelet alatt függvényt értesz? Mert úgy kellene. Írj egy példát, hogy mi nem működik.
A RecordSet-ben az általad írt mezőnek értéket adó művelet így néz ki:
Code:rs.updateString("name", "Pityuka");Amennyiben a rekordban nincs "name" mező, ez futásidőben derül ki.Az aktív rekordban így néz ki:
Code:ar.name="Pityuka"Ha nincs name mező, ez fordítási időben derül ki.
Először is az első egy adatbázisba ír egy name oszlopba egy Pityuka sztringet, a másik pedig csak egy memóriaterületre ír egy struktúrába, továbbá a második önmagában csak a Pityuka sztinget tartalmazza a name oszlopot nem. Ergo a nem sztinget a rekordtól függetlenül bele kell írnod valahogy, pl.:
Code:rs.updateString("name", ar.name);De, ha még lenne is egy ar.columname="name", akkor sem értem, hogy mivel "jobb" a name stringet változóként, mint függvény paraméterként megadni. Ráadásul, ha így konstans, akkor eleve fordítási időben (azelőtt) adod meg.
Igaz, persze az oszlopokat sorszámuk alapján is be lehet azonosítani és akkor nem kell a “name”, de ez meg igaz mindkettőre.
Igazad van, az aktív rekordban az ar.name=”Érték” nem kerül rögtön tárolásra, hanem az ar.save(); művelet menti el az adatbázisba.És miért jobb? Mert fordítási időben ellenőrzi, hogy jó helyre jó dolgot írok-e, van-e annak a táblának olyan mezője.Én buta vagyok, és azért szeretem az erősen típusos nyelveket, mert rengeteg hibát kidobank még fordítási időben.Számomra könnyebben áttekinthető a kód is, ha egy műveletem eredménye vagy paramétere nem ResultSet, ami bármilyen rekordszerkezet lehet, hanem annak egy nevesített osztálya, ami csak egyféle szerkezetet takarhat.Az már csak hab a tortán, hogy nekem kényelmesebb is, de lehet, ez már csak megszokás kérdése.
Az előző hozzászólások nagy részére nem reagálok, mert szofverarchitektúra tekintetében szerintem a végtelenségig elbeszélgetnénk 🙂Visszatérek az Active Record témára, a technikai kihívás miatt. Találtam egy szerintem kipróbálásra érdemes implementációt:http://code.google.com/p/activejdbc/A keresés így működik:http://code.google.com/p/activejdbc/wiki/RecordSelectionA "fő" osztály, amiben érdekes dolgok vannak, itt van:http://code.google.com/p/activejdbc/source/browse/trunk/activejdbc/src/main/java/org/javalite/activejdbc/Model.java
Code:
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz