Hozzászólások
-
Szerző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?
Azt hiszem, az oszlopokat hagyjuk, mert bár azt írod, hogy az oszlopokat nem kell betöteni mindet, a kereső mégiscsak szépen végigmegy az összes oszlopon, míg meg nem találja a keresettet, azaz a keresett értékeket be kell tölteni, ha nem is mindet, de a keresésig. Ez ugye nem indexelt keresés, számomra nem is fontos.A rekordok keresésére azonban nem tudom rávetíteni, mivel ott úgyis az sql fog keresni és nem én, nekem meg lesz 1 darab eredmény tömböm a mezőadatokkal.Emiatt akkor még mindig nem látom célját a tárolónak. Legalábbis a rekordokat tárolóba nem tenném. A mezők persze tárolóban vannak.Majd persze lesz olyan művelet, ami több rekordot ad vissza, annak az eredménye természetesen tároló, de én egyelőre a findByPK() műveletet szeretném tisztázni, aminek az eredménye mindig 1 db rekord (vagy null).Itt lenne szükségem arra, hogy az eredmény különböző osztályú legyen. Például UserRecord, vagy ItemRecord, vagy bármi, ami AR leszármazott.
Rendben, egyelőre megpróbálom megérteni amit írsz:Mit keres itt a List? Azon kívül, hogy van egy ilyen tároló, mi köze az adatbáziskezeléshez?A lista elemeket tárol, de nekem csak 1 elem kell, épp amelyikkel dolgozni szeretnék. Miért kell egy elemhez tároló? Vagy az egész táblát kellene tárolnom listában? A listának valóban van kereső művelete, de ez a listában tárolt adatokban keres, ha jól tudom, és nem a táblában. Hogyan fog ez nekem keresni a táblában?(Arról nem is szólva, hogy hogyan keres egy lista majd egy összetett SQL kifejezéssel?)
Megrpóbáltam beazonosítani a Te fogalmaidat az enyémekkel, lehet, hogy nem sok sikerrel.Nálam van egy AR osztály, amiben implementálva lenne az adatbáziskeresés, és erre épülnek a konkrét táblákat kezelő aktív rekordok, mint például a UserRecord.Ha jól látom, az én AR osztályom helyett használod Te a
Ne haragudj, de nem igazán értem amit írsz. Ha a konkrét esetre vonatkoztatva írnál egy picit konkrétabb példát, lehet, hogy könnyebben felfognám.Most valami ilyent gyanítok a konkrét esetre, de eléggé nem tiszta:
Code:class Finder {Kezd egész bíztatóan alakulni! Már csak a statikus műveletekkel van gond.Keresni már lehene így:
Code:class UserRecord extends AR {A szintaxis a következő:
Code:class AR {Code:class AR {public static findByPK(long id) { ... }Köszönöm, de sajnos nem pont erre gondoltam. Valóban, a class UserRecord extends AR. Amit én keresek, az a findByPK(long id) művelet definíciója, mert ugye azt nem írhatom, hogy
Code:public static AR findByPK(long id) { ... }És azt sem - mivel az AR osztályban definiálnám -, hogy
Code:public static UserRecord findByPK(long id) { ... }Tehát, már definiálni sem egyértelmű. Az meg külön kérdés, hogy a művelet törzsében hogyan definiálom a visszaadott objektumot, hogy ha a műveletet a UserRecord-ból hívom meg, akkor az eredménye UserRecord legyen.
Code:AR record = new AR(); // Jó lenne, ha már itt egy objektumfüggő típusú változóm lehetne ...record.setDataFromCursor(getCursorFromId(id)); // Ez valami művelet, ami kimazsolázza az adatbázisból, majd betölti az objektumba.return record; // Na, itt már UserRecord objektumot kéne visszaadni, de ez sajna nem az.Talán valami generic szerűség kellene, de nem tudom, hogyan ...
Azért szívesen belenyúlok, ha valami extrát akarok csinálni, de hogy azért nyúkáljak napokig, hogy a bluetooth elinduljon, na ezt akarnám elkerülni …Azt élvezem is a linuxban, hogy az egyedi igényeimhez tudom szabni, de szeretném elkerülni, hogy mindent meg kelljen tanulnom, amit használni akarok. Egy ideig az Ubuntu ebben jó volt, de mostanra tényleg nagyon összeesett.A Mintről pedig nem tudatosult bennem ez a két verzió. Biztos, hogy nem az Ubuntus ágat fogom követni ... 😉Köszönöm!
-
SzerzőBejegyzés
legutóbbi hsz