ugrás a tartalomhoz

OOP alapú rekord kezelés

H.Z. v2 · 2011. Júl. 7. (Cs), 22.25
Elakadtam(kissé belezavarodtam) már megint: ha létrehozok egy osztályt, aminek a dolga egy fix típusú adatrekord modellezése lenne (mondjuk egy darab user adatai, egy darab blog bejegyzés adatai stb.), akkor milyen feladatokat lehet/kell/szabad elvárni tőle?
Ami tiszta('nak tűnik) :
- ő tárolja az adatokat
- az egyes mezők tartalmának módosításakor ellenőrzi, hogy érvényes adat érkezik-e a setter metóduson keresztül (????? ez az ő feladata? )
- az insert/delete/update/select metódusokon át kiadja a szükséges SQL parancsokat.
(tehát egyetlen rekord beszúrását, törlését, update-elését a tárolt adat kulcsa alapján)

De:
kell-e foglalkoznia tranzakció kezeléssel? Feladata lehet-e optimistic concurrency controlt használva, az adatok változatlanságának ellenőrzése?
Milyen szinten kell törődnie azzal, hogy a kiadott SQL-ek hibátlanul értek-e véget?
Pl.azzal, hogy az adatbetöltés sikertelen volt, mert nem létező kulcs alapján akartam betölteni valamit? Vagy: amikor azt várom, hogy egyetlen soron hajtódott végre az SQL, de azt kapom vissza, hogy egynél több sort érintett az SQL?


Én úgy saccolom, hogy már megint tévúton járok és a "De:" után felsorolt kérdésekre csupa-csupa nem a válasz. Egyre inkább az az érzésem, hogy már megint fordítva ültem fel ama bizonyos pacira. :-)
 
1

DataMapper

Protezis · 2011. Júl. 7. (Cs), 23.06
Nézz utána a DataMapper mintának például itt: http://martinfowler.com/eaaCatalog/dataMapper.html
Ahelyett, hogy feltalálnád újra a kereket, miért nem ismerkedsz meg mondjuk a Doctrine2-vel?

Ajánlom még ezt a blogbejegyzést: http://giorgiosironi.blogspot.com/2009/11/whats-going-on-with-php-object.html
2

Köszi! Kerékfeltalálás

H.Z. v2 · 2011. Júl. 7. (Cs), 23.17
Köszi!
Kerékfeltalálás témában: egyelőre nem akarok keretrendszert használni. Főképp azért, mert amíg az alapokkal nem vagyok eléggé tisztában, addig csak plusz szívást jelenthetnek.
A kérdésem is inkább elvekre vonatkozik, nem kifejezetten a rekordkezelés a lényeg (számomra).
4

Az ActiveRecord

Protezis · 2011. Júl. 8. (P), 00.07
Az ActiveRecord megvalósításban - mint amit a legtöbb PHP-s ORM rendszer követ - az alapvető műveleteket ezek a model osztályok biztosítják: de csak azokat, amelyek egy adatbázis rekordon értelmezhetők.

Nyilván absztrakt megoldásokat érdemes használni, az ORM-ek esetén sem a delete() metódusban van az sql query, így az esetleges tranzakciókezelés sem ott van.

Azonban én az ActiveRecorból kiszerettem, problémás a használata (persze mihez képest). Gondolj bele: egy felhasználó objektumnak mit kell csinálnia? Alapvetően semmit, adattárolásra használjuk. Miért kell arról tudnia, hogy van ő letárolva adatbázisban? Egyáltalán miért kell tudnia arról, hogy van adatbázis?

Még két érdekes cikk.
5

Nyilván absztrakt

H.Z. v2 · 2011. Júl. 8. (P), 05.34
Nyilván absztrakt megoldásokat érdemes használni, az ORM-ek esetén sem a delete() metódusban van az sql query, így az esetleges tranzakciókezelés sem ott van.


Ezzel most elbizonytalanítottál... Ha pl. a delete metódusban nincs query, akkor hol van? (már feltéve, hogy egyről beszélünk és a DELETE SQL parancsot is query-nek nevezzük).

Próbálom a másik oldalról megközelíteni a dolgot: az adatot leíró objektumnak vannak ugyan insert/delete/update metódusai, de ezek csak a rekord memóriabeli tárolására vonatkozó esetleges műveleteket hajtják végre, az adatbázisban v. egyéb tárolóban végzendő műveleteket egy driver segítségével intéznék, de itt egészen alapvető gondjaim vannak... (pl. hogyan talál rá a driverre, a driver - ha független a rekordtól, honnan fog értesülni róla, hogy milyen specifikus műveleteket kell elvégeznie stb.)

Ha felébredtem, átnézem a linkeket...
7

Nézz utána a Unit Of

Protezis · 2011. Júl. 8. (P), 07.59
Nézz utána a Unit Of Work-nek. A Doctrine 1 active record megvalósítást használ, nézd meg a delete() metódust itt: attól még, hogy egy modelnek hívhatod a delete() metódusát, a queryket külön osztályok építik fel és zárják tranzakcióba.

ORM írásnak csak akkor állj neki, ha nem vársz tőle használható eredményt és/vagy csak a fejlesztése közben felszedett tudás a lényeg.
8

Az utolsó mondatod utolsó

H.Z. v2 · 2011. Júl. 8. (P), 08.06
Az utolsó mondatod utolsó tagmondata kb. 100%-ban fedi a (múltbéli?) céljaimat. :-) Egyre többször jut eszembe, hogy feladom.

Köszi!
3

kerék

joed · 2011. Júl. 7. (Cs), 23.56
nem ördögtől való egy-egy keretrendszer használata, van ami nem erőlteti rád saját mintáit, ugyanakkor élvezheted az előnyeit, mint pl. az adatbázis absztrakció. Ezért én a kerék újra feltalálása helyett, hallgatnék Protezis kollégára és megnézném, hogy oldják meg ezt a problémát a "nagyok". Doctrine, Zend Framework szvsz jó irány. Ha nem is használod őket végül, mindenképp megválaszolhatják néhány kérdésed.
6

Ez igaz és nézegettem is a

H.Z. v2 · 2011. Júl. 8. (P), 06.02
Ez igaz és nézegettem is a doctrine-t, meg még inkább a propel-t, de ezek bonyolultabbnak tűnnek annál, hogy egy (na jó, pár...)órányi olvasgatás árán használni tudjam őket.
A forráskódban (propelében) meg egyszerűen elvesztem, amikor valami konkrétumot próbáltam keresni.

Az már csak mellékszál, hogy amíg nem tudom, miért kell valaminek úgy működnie, ahogy... addig nem szívesen használok olyan alkatrészeket, amik eltakarják előlem a lényeges(nek tűnő) dolgokat.
Egy időre azt hiszem, megszűnök. Úgy képzeltem, ennél gyorsabban el tudok indulni valami kezdeménnyel, amit később viszonylag egyszerűen lehet bővítgetni, csinosítgatni...