php keretrendszerek ii.
Az előző részben ott tartottunk tehát, hogy ma már nem feltétlen a CodeIgniter a kedvenc keretrendszerem, de mielőtt továbbmennék meg kell jegyeznem, hogy ez nem egy keretrendszer-összehasonlító teszt, csupán egy szubjektív poszt a témáról.
Szóval ott tartottam, hogy a CodeIgniter már-már tökéletes megoldás. Igen ám, csak hogy a fejlesztői nem a keretrendszer támogatásából élnek, hanem egy fizetős tartalomkezelő rendszerből, amit ugyan folyamatosan portolnak a keretrendszer alá, de a CodeIgniter magjának fejlesztésére mintha nem jutna elegendő energia. Másfelől a fejlesztő cég feje is elismerte, hogy ők a keretrendszert a lehető legminimálisabb szinten akarják tartani. Tulajdonképpen nincs is ezzel baj, azonban ismét kezdtek előjönni azok a problémák, hogy mások kódját kezdtem el használni kisebb-nagyobb problémák megoldásához, amikor nem akartam újra feltalálni a kereket. Igaz ez immár sokkal egységesebbnek tűnt, lévén mindegyik a CodeIgniter filozófiáját és kódolási stílusát követte, de megesett, hogy három projektben három különböző megoldást voltam kénytelen használni valamiért egy adott problémára.
Egyszer aztán egy komolyabb munka miatt több új és több régi könyvtárat kellett volna beépítenem a weboldalba. Körülnéztem és akármelyiket néztem, mindegyik felmerülő problémára találtam egy Kohana könyvtárat, amit a Kohana fejlesztői írtak, dokumentáltak és támogattak. Aki esetleg nem ismerné a Kohanát, annak mondom, hogy itt egy olyan keretrendszerről van szó, amit eredetileg a CodeIgniterrel elégedetlenkedő felhasználók írtak és amennyire tudom az eredeti kód alapja is maga a CodeIgniter volt. A történelmének nagyon nem jártam utána, de amennyire tudom, az elégedetlenség fő oka a CodeIgniter php4 támogatása volt, mert szerintük emiatt a kód nem elég tiszta, stb. Na most annak idején (talán még 2008 elején) én nézegettem a Kohanát, de akkor nekem még egyfelől a php4 támogatás mindig fontos volt, másrészt a Kohana akkoriban nagyon rosszul volt dokumentálva. Most viszont ott találtam magam egy projektben ami eleve php5-ös szerveren futott, másfelől azt találtam, hogy a Kohana dokumentációja nagyságrendileg azonos részletességű, mint a CodeIgniteré, ráadásul a két projekt szintaxisa, felépítése is igencsak hasonló. Elkezdtem hát használni a Kohanát és pillanatokon belül azon kaptam magam, hogy ez a rendszer maga a Kánaán. Az ORM rendszere, az Auth modul, a cache támogatás és a fájl kaszkádlás mind-mind azonnal megnyertek maguknak. Ráadásul szerintem a sebessége se rosszabb, mint a CodeIgniternek, noha a Hello World jellegű versenyekben rendre alulmarad a CodeIgniterrel szemben.
A Kohana fejlesztése ráadásul elég ütemes, igaz a jelenlegi tervek szerint a Kohana fejlesztői a Drupálhoz hasonlóan két verzió egyidejű támogatását tervezik, amikhez meglátásom szerint kicsi a támogató team. Mindenesetre hamarosan jön a Kohana 3. verziója, benne az ígéretek szerint minden földi jóval. Majd meglátjuk.
Ami viszont biztos, hogy jelenleg a Kohana kettes verziója stabil és nagyon jó szoftver a maga nemében, viszont sajnos erősen épít a Singleton tervezési modellre, ami nagyon egyszerű, a maga módján hasznos is, viszont tesztelhetőségi szempontból nagyon káros. Hogy ez alatt mit kell érteni azt igyekszem minél hamarabb kifejteni, most maradjunk a témánál.
A korábban említett összetett projekt immár fél éve zajlott, amikor igazán megértettem, hogy mennyire fontos az állandó tesztek futtatása. Idő közben kísérleti jelleggel belecseppentem a Kohana tesztelési projektjébe is, majd magam is kezdtem behatóbban megismerkedni a dologgal. Először talán a Google Talk videók között leltem néhány hasznos előadásra (Unit Testing, Inheritance, Polymorphism & Testing, Global State & Singletons, Don't Look for Things!) és meg sem álltam Miško Hevery blogjának átolvasásáig. Valószínűleg ebben a témában fogok először komolyabban elmerülni a blogomon, de addig is, akinek kedve van, nézelődjön a fenti linkeken, csak hasznára válhat.
Na jó, tehát arra már rájöttem, hogy a Kohana nem a legjobban tesztelhető rendszer a világon, gondoltam ideje szétnézni, hogy vannak-e profibb rendszerek. Az első számomra valamelyest egyértelmű lépés az volt, hogy a már korábban már kerülgetett, de valahogy mindig túl bonyolultnak találtatott Zend Framework-öt vettem górcső alá. Azt addig is tudtam, hogy a Zend mögött komoly bázis áll, hiszen eleve ők "A PHP's cég", legalábbis saját állításuk szerint biztosan. A Zenddel való ismerkedésem sajnos sokkal nehézkesebb volt, mint a két könnyűsúlyú rendszer esetében és ennek első számú oka az volt, hogy a bevezetőnek szánt oktató cikk egész egyszerűen nem működött, ha az ember Windows alól próbálta meg követni. Később aztán megkerestem a hibát és el is küldtem a fejlesztői gárdának, úgyhogy most már gyanítom mindez működik. Ezalatt és némileg ez után még jobban elmerültem a kódban és a dokumentációban és el kellett ismernem, hogy elképesztő mennyiségű minőségi munka van a projektben. Ugyanakkor azt továbbra is meg kellett állapítanom, hogy a Zend Framework használata elsőre (és másodszorra is) elég nehézkes, viszont valószínű, hogy ha az ember készség szinten elsajátítja, akkor nagyon jól testre szabható alkalmazások készíthetőek vele.
Ami a Zendben jól láthatóan különbség mondjuk egy CodeIgniter rendszerhez képest az számomra a következő:
A ZF mindenre, a CodeIgniter csak a legnyilvánvalóbb feladatokra kínál megoldást
A ZF gyakorlatilag teljesen moduláris, tehát csak azt a részét kell betölteni, amit az ember ténylegesen használ, míg a CodeIgniter néhány osztályt mindenképp betölt
ZF-ben az egyes megoldások részletesen ki vannak dolgozva, sokszor alternatívákkal együtt, a CodeIgniterben ezzel szemben a legtöbb feladat megoldása 1-1 okos kis osztályban merül ki, melyek viszont sokszor túl sok feladatot végeznek el.
A CI jelentősebb módosítások nélkül csak MVC stílusban használható, a ZF az MVC-t támogatja és ajánlja, de nem teszi kötelezővé.
Fentiek miatt a ZF-ben egy Hello World sebessége elvileg megegyezik egy PHP "Hello World"-del (lévén nem kell betölteni hozzá semmit a rendszerből), viszont ha már MVC keretrendszerként akarjuk használni, akkor lehet, hogy lassabb lesz, mint a CI. Ugyanakkor ez véletlen sem jelenti, hogy rosszabb hatékonysággal lenne megírva, egyszerűen csak sok több funkciót implementáltak, hogy meggyorsítsák egy komoly fejlesztés érdemi részét.
És ha már tesztelhetőségről ejtettünk szót, mint fő mozgató rugó a Kohana elhagyásában, említsük meg, hogy a ZF-ben ez a probléma önmagában nem létezik, ugyanis ott ezeknek a Singletonoknak a kezelése vagy kikerülése a programozó dolga, emiatt viszont érdemben mondhatjuk, hogy a ZF jól tesztelhető keretrendszer. Igen ám, de a ZF azért arra nem ad választ, hogy hogyan kerüljük el a Singletonok használatát. Pontosan erről fog szólni viszont a harmadik a sorozat következő része.
A bejegyzés trackback címe:
Kommentek:
A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben és az adatvédelmi tájékoztatóban.
