Weblabor

Ezúttal egy az adatbáziskezeléssel kapcsolatos témáról lesz szó. A cikk első felében egy módszert mutatok be, melynek alkalmazásával jól elkülöníthetőek az adatok mentésével, módosításával kapcsolatos kódok programunk egyéb részétől. A második részben arról lesz szó, hogy hogyan tudjuk az adatbáziskezelés során fellépő hibákat minél egyszerűbben kezelni. Már itt jelezni szeretném, hogy ennek a résznek a második fele némiképp egy gondolatkísérlet, vitaindítónak szánom. Ezt a megközelítést még nem nagyon láttam máshol leírva (lehet nem véletlenül), így kíváncsian várom majd a véleményeket vele kapcsolatban.

Kapcsolódás

Mielőtt bármit is tennénk, az első lépés, hogy kapcsolódunk az adatbázishoz. Itt jegyezném meg, hogy a példákban az ADODB adatbáziskezelő réteget fogjuk használni. Általában célszerű, ha egy ilyen jellegű eszközt használunk. A fő érv emellett többnyire, hogy jól jöhet, ha szeretnénk alkalmazásunk alatt lecserélni az adatbáziskezelőt (DBMS). Erre azért viszonylag ritkán van szükség, számomra sokkal fontosabb, hogy a különböző típusú adatbázisokat egyazon API-n keresztül érhetem el. Ráadásul az ADODB nagyon sok hasznos funkcióval rendelkezik, mindenkinek ajánlom, hogy legalább egyszer nézze meg, próbálja ki. De aki nem szereti, más a kedvence, az se riadjon el, mert a bemutatott elvek bármilyen réteg vagy akár a natív függvények használata esetén is alkalmazhatóak.

A kapcsolódásnál tartottunk. Én erre a következő kis osztályt ajánlom.Mielőtt magyarázatra kerülne sor, lássuk, hogy hogyan is használhatjuk.Bárhol, ahol szükségünk van adatbáziskezelésre, ott a fenti módon csatlakozhatunk. A módszer előnyei:

• Az adatbáziskezelő kódok csak akkor kerülnek betöltésre, amikor ténylegesen szükség van rájuk. Például ha a kérésben szereplő adatok elbuknak az ellenőrzésen, akkor felesleges időveszteség lenne ezen kódok parse-olása.
  
• A konkrét kapcsolati paraméterek megadása helyett bejön egy plusz réteg. Alkalmazásunk minden egyes modulja például a saját nevén kérheti el a kapcsolatot. Ezután ha valamiért mégis másik adatbáziskezelőre volna szüksége, akkor ezen az egy központi helyen beállítom, hogy például a "SESSION" kapcsolat esetén nem az alapértelmezett, hanem egyéb paraméterekkel történjen a kapcsolódás.
  
• Nincs szükség egy globális változóban tárolni a kapcsolatot, így programunk szervezése is szebb lesz. A tényleges kapcsolódás az első kérés esetén történik, a kapcsolatot megtestesítő ADODB objektumot egy statikus tömbben tároljuk, majd ezt követően, ha ugyanezen paraméterekkel rendelkező kapcsolatot kérünk, akkor ennek referenciáját kapjuk vissza. Így a többlet munka elenyésző, a cserébe kapott rugalmasság sokkal többet ér.
  

Függetlenség az adatbáziskezelőtől

Fentebb említettük, hogy az adatbáziskezelő rétegek használatának egyik oka, hogy szeretnénk alkalmazásunkat függetlenné tenni az éppen alkalmazott adatbázistól. Ez azonban csak az első lépés. Ha alkalmazásunkban mindig közvetlenül adunk ki SQL utasításokat a szükséges helyeken, akkor ezek a kódok szanaszét átszövik programjainkat. Az egyes SQL nyelvezetekben azonban lehetnek eltérések, illetve egyéb funkcionális különbségek (pl. Oracle esetén limit), ha váltani szeretnénk, akkor elkerülhetetlen, utasításainkon apró módosításokat kelljen eszközölnünk. Viszont a fenti kódszervezés esetén óriási munka lehet felkutatni az összes SQL utasítást, és ellenőrizni azok megfelelőségét. Ennek elkerülése érdekében érdemes az adatbázis kezeléssel kapcsolatos kódokat elválasztani az alkalmazás többi részétől. A következő részben arról lesz szó, hogy ezt hogyan érdemes megtenni.

Data Access Object - DAO

Az adatbáziskezelő kódokat logikailag összetartozó csoportokba válogatjuk, minden egyes ilyen csoport egy úgynevezett DAO osztályt fog alkotni. Például az article táblánkhoz tartozik egy ArticleDao osztály, melyen keresztül tudunk cikkeket hozzáadni, módosítani, törölni az adatbázisban. Nem véletlenül logikai csoportosításról van szó, nem fog feltétlenül minden egyes táblához egy ilyen osztály tartozni. Ha például van egy táblánk, melyben tároljuk egy cikk esetén a hozzá kapcsolódó cikkeket, akkor ennek kezelését szintén az ArticleDao osztályunk fogja elvégezni. Még lesz szó arról, hogy mit is érdemes egy ilyen DAO osztályba betenni, de előbb lássunk egy egyszerű infrastruktúrát ezen osztályok kényelmes használatára.

Először is legyen egy alap DAO osztályunk, melyből származtathatjuk a többi ilyen jellegű osztályt. Ez kezdetben nagyon egyszerű lesz: konstruktor, illetve az ADODB hibaüzeneteinek "kivezetése".Egy példa egy konkrét DAO objektumra.A kényelmes használathoz még meg kell oldjuk, hogy bármikor könnyen hozzáférjünk ezekhez az objektumokhoz. Ehhez ismét a factory tervezési mintát hívjuk segítségül.A fenti kód azt feltételezi, hogy a DAO osztályainkat a DIR_INCLUDE_DAO konstans által meghatározott könyvtárban tartjuk, illetve, hogy a "User" DAO-t a UserDao.php fájlban definiált UserDao nevű osztály valósítja meg. Ha mindezzel megvagyunk, akkor a használat már pofon egyszerű.Már csak szemre is tetszetős, nem? ;) Ez is egy nagy előny, hogy az adatbázis kezelő kódok kivonásával programunk olvashatósága is megnő, jobban követhető annak logikája. Ezenkívül egy plusz előny, hogy DAO osztályaink felépítése, alap funkcionalitása (add(), delete(), update(), get(), getList()) hasonló lesz, így egy már kész osztályból gyorsan létre tudjunk hozni egy újat viszonylag kevés módosítással. Illetve itt jegyezném meg, hogy lehetőségünk van ezen DAO objektumok adatbázis séma alapján történő automatikus generálására (PEAR::DB_DataObject, Propel, Metastorage, DaoGen), de ez nem témája jelen cikkünknek.

Felelősség

Fontos, hogy kellő figyelmet fordítsunk arra, hogy DAO objektumainkban csak olyan funkciókat valósítsunk meg, melyek ténylegesen az adatbázis eléréshez kötődnek. Könnyen kísértésbe eshetünk, hogy olyan funkciókat is ide tegyünk, melyek az üzleti logikához kötődnek. Például tegyük fel, hogy van egy olyan függvényünk mely visszaadja az adott tábla rekordjainak azonosító és név mezőjét. Erre például egy select lista generálásakor lehet szükségünk. Egyből adódhat az ötlet, hogy a függvény már egyből az option listát adja vissza, így könnyebb használni is. Ez azonban nem túl szerencsés (tervezési hiba), a függvény adja csak vissza egy tömbben a szükséges adatokat, és legyen egy külön függvényünk/osztályunk, mely ezen tömb alapján legenerálja a select listát.

Előfordulhat azonban olyan szituáció is, amikor egy DAO osztály nem csak az adatbázissal foglalkozik. Ilyen helyzet lehet például, ha az adatbázisban tárolt adatokhoz fájlrendszerben tárolt állományok is kapcsolódnak. Ilyenkor ezek kezelése a DAO objektum felelőssége, fontos, hogy a fájlok és az eltárolt információk konzisztensek maradjanak.

Hibakezelés 1

Mint minden más esetben a programozás során fontos a hibák ellenőrzése, megfelelő kezelése. Hiába ellenőrizzük bejövő adatainkat alaposan, adódhat olyan helyzet, amikor az adatok szintaktikailag jónak tűnnek, de a belőlük összeállított SQL utasításunk hibát fog generálni, mert valamilyen megszorítás (egyediség, hivatkozási épség, stb.) nem teljesül. A hibakezelésre egy lehetséges megoldás lehet az alábbi, de ehhez szükséges, hogy az általunk használt adatbázis kezelő megfelelő hibaüzenetet adjon vissza. Ez például MySQL esetén nem teljesül, de sajnos nem ez a legnagyobb hibája, ami miatt nem érdemes használni.A megoldás lényege, hogy a hibaüzenetben rákeresünk a hiba okára utaló szavakra. Ez így kicsit bizonytalannak tűnhet, de gyakorlatban jól bevált módszer. Persze némi odafigyelést igényel. Cserébe viszont nem kell "kézzel" megnéznünk, hogy a beszúrandó loginnév, email használva van-e már, egyszerűen megpróbáljuk beszúrni az adatokat, és a megfelelő oszlopokon elhelyezett egyediséget biztosító megszorítások elvégzik a piszkos munkát. Ha nem sikerül a hibát felismerni, akkor false-t adunk vissza. Ez általában csak akkor történhet meg, ha valamilyen hiba van a programunkban, vagy a lekérdezés hibás. A lehetséges hibák jelzésére konstansokat hozunk létre, melynek célja szintén a kód olvashatóságának növelése. A hívó fél oldaláról ez így néz ki.

Hibakezelés 2

Most következik az a rész, melyről a bevezetőben írtam, hogy vitaindítónak szánom. Ez mostanában kristályosodott ki bennem, jól használható dolognak tűnik, de még nem egy agyonhasznált, többféle környezetben kipróbált módszer.

Ha megnézzük, akkor a fent bemutatott módon kezelt hibák egy jó része az alkalmazás elkészültével normális használat mellett nem fordulhat elő. Jöjjön egy példa egyből, ami az előző mondatot érthetőbbe teszi. Például ahogy fent is említettem a return false ágak nem fordulhatnak elő, csak ha konkrét programozási hiba van. Elegendő lenne, ha ezek a hibák jelzésre kerülnének, de nem szükséges a kezelésükre külön figyelmet fordítani, hiszen ezek a hibák hamar kiderülnek (már minimális tesztelés esetén is), a végső rendszerben biztosan nem lesznek jelen. Egy másik ide sorolható hiba például a hivatkozási függőség nem teljesülése. Általában a kapcsolódó dolgokat egy select listából választva tud a felhasználó egy másik dologhoz rendelni. Ha én ezt jól generálom, és a felhasználó ebből választ, akkor nem lehet gond. Ha felteszem, hogy jól generálom, illetve ellenőrzöm, hogy választott-e, akkor csak egy esetben adódhat ebből a szempontból hibás lekérdezés, ha a felhasználó megpróbál a felületet megkerülve adatokat eljuttatni a rendszerhez.

Szóval a lényeg, hogy az alkalmazásban olyan hiba ágakat kezelek le, amelyekbe normál működés mellett nem kerülhet az alkalmazás. Erre találtam ki, hogy a hiba okának kiderítése helyett ezekben az esetekben a trigger_error függvény segítségével PHP errort generálok, úgy, hogy a hibaüzenet egy speciális karaktersorozattal kezdődik, így a saját hibakezelő függvényem ezeket meg tudja különböztetni az egyéb hibáktól. Ennek támogatásához némileg módosítsuk az alap DAO osztályunkat:És a magyarázat előtt jöjjön egyből egy példa is a használatára.Mint látható kétféle "extra" hibát különböztetek meg. Az egyik kategória a biztosan fejlesztői hibából származó hiba. A neki megfelelő prefix-szel ellátott hibaüzenetet a getDevError() függvény adja vissza. Például minden DAO metódus végén dobok egy ilyen üzenetet. Ide viszont csak akkor kerülhet a program futása, ha a lekérdezés hibás volt. Fejlesztési időben ez nagyon hasznos, egyből, erőteljesen látom, ha rosszul van a lekérdezés összeállítva. A másik kategória az, amikor csak akkor lehet hiba, ha "hackelés" történik. Normál működés esetén nem fordulhat elő, hogy a módosításkor egy nem létező azonosítót kapok vissza.

Ezután már csak annyit kell tennem, hogy a hibakezelő függvényemben figyelem a hibaüzeneteket, és ha az említett prefixek egyike megtalálható benne, akkor a hiba típusától függően reagálok azokra. Például "fejlesztői hiba" eseten mehet egy egységes képernyő a felhasználónak, melyben étesítem, hogy a szolgáltatás jelenleg nem elérhető, és persze megy a levél a fejlesztőnek, hogy valami nem kerek, "felhasználói hiba" esetén pedig szintén lehet egy egységes képernyő, melyben finoman közöljük, hogy a felhasználó nem rendeltetés szerűen használta az oldalt (plusz szintén levél a fejlesztőnek). Ha valaki saját hibakezelőt szeretne írni, előtte mindenféleképpen ajánlom, hogy nézze meg a Papp "Chemotox" Győző által készített Errorhandlert.

Ez a módszer egész jól működni látszik, tranzakciókezelés során sincs gond, ugyanis ilyenkor a script leállása automatikusan Rollbacket von maga után. Illetve a MySQL-lel már megint baj van, ugyanis pconnect() használata esetén ez nem történik meg, beragad a tranzakció, és az esetleges lockolások is, melyek csak az adatbázis újraindításával hozhatók rendbe. Ha mégis pconnectre van szükség, akkor esetleg egy shutdown függvény segítségével orvosolható a probléma, ugyanis ezek a függvények hiba esetén is lefutnak a script leállása előtt, így ebben mondhatunk egy Rollbacket ha épp tranzakcióban voltunk.

Nagyjából ennyit szerettem volna mára, kíváncsian várom a véleményeteket.