Tartalom
Kérdezd meg, melyik keretet használjam, és valószínűleg egy rosszkedvű öregasszony pillanatom lesz, és mondd el, hogy minden keret ugyanolyan rossz, mint egymásé. Ami nem azt jelenti, hogy mind rosszak, pontosan, de a PHP-ben elképzelhetetlenül sok keretrendszerünk van (általában N + 1 néven említik, ahol N a PHP fejlesztők száma a világon), és valószínűleg mindegyiknek volt értelme annak a személynek, aki feltalálta őket.
A keretek választása valószínűleg jobb, mint csak egy keretrendszer használata, függetlenül attól, hogy pontosan mit akartál felépíteni, mert ez a „legjobb” (a „legjobb” bármilyen mértékétől függetlenül). Ez a keretkínálat kiválasztása azt jelenti, hogy kiválaszthat valamit, ami megfelel a projekt igényeinek, és akár dokumentálható is lehet. Bármely platformon a keretrendszerek valóban ott vannak, hogy struktúrát, újrafelhasználható modulokat és könyvtárakat biztosítsanak, és általában elkerülik az unalmas és ismétlődő feladatokat, amelyek ugyanazon funkcionalitás kiépítéséhez kapcsolódnak. Például CMS-ek létrehozásakor valaminek feldolgoznia és érvényesítenie kell az űrlapmezőket számomra; ha magamra hagyom, kihagyhatok valami fontosat, és sokkal inkább szeretném megtenni az egyes projektek elemeit különböző, nem pedig azok, amelyek minden alkalommal ugyanazok!
Teljes kötegű keretek
A teljes veremű keretrendszerek, például a Zend Framework, nagyszerű kiindulópont lehet egy fejlesztő számára, sok építészeti tapasztalat nélkül. Jó struktúrát ad az új alkalmazás felakasztására, és jó „ökoszisztéma” van körülötte - rengeteg könyv, oktatóanyag és ésszerű dokumentáció is. Ha olyan nagy alkalmazást próbál létrehozni, amelyet sok ember fog fenntartani, akkor egy népszerű, átfogó keretrendszer valószínűleg jó választás, mivel elég sok struktúrát diktál, jól ismert és megértett.
A szétválasztást segítő struktúra mindig jó; karrierem elején dolgoztam néhányal nagyon junior fejlesztők és megkísérelte megtanítani nekik az MVC (Model View Controller) mintát, amely akkoriban viszonylag új volt. Hoztuk a döntést, hogy a nézetrétegben Smarty-t használunk; részben azért, hogy a tervezők könnyebben tudjanak dolgozni a sablonokkal, másrészt pedig, hogy amikor valaki odajött az asztalomhoz, és azt mondta: "Hogyan csináljam X-et Smarty-val?" Mondhatnám, hogy "ne csináld az X-et a nézetben!" (tízből kilencszer ez volt a válasz). A keretek megléte segít abban, hogy ugyanazt az elkülönítést találjuk meg alkalmazásunk más részeiben is. Közülük sokan támogatják az integrációt egy olyan sablonréteg ellen, mint a Smarty vagy az új kedvencem, a Twig, így ezeket az eszközöket magával viheti bármelyik keretrendszer mellett.
Könnyíteni a terhen
Rengeteg könnyebb keret van, mint a Zend Framework, például elég sokat dolgozom a CodeIgniterrel. Olyan átfogó és robusztus, mint a Zend Framework? Nem, nem az. De mint segítő keretrendszer, amely lehetővé teszi az alkalmazás gyors felépítését, hasznos. Általánosságban elmondható, hogy a kevésbé „segítő” funkcionalitású keretrendszerek könnyebben eligazodhatnak, mivel sokkal nyilvánvalóbb, hogy a darabok hogyan állnak össze. Egy ismeretlen keretrendszerben (számomra ez nagyjából minden) az automatikai bitek nehezítik a munkát és a hibakeresést.
Ez az érzés, hogy „elvesznek egy új keretben”, elkerülhetetlen és teljesen elkeserítő; még egy tapasztalt fejlesztő is újoncnak érzi magát, amikor nem tudja, hogyan működik bármi. Ha igazán nincs szerencséd, akkor kiválasztottál egy keretet, amelynek IRC csatornája megmondja, hogy te is idióta vagy! Ez a nagyon negatív kezdeti tapasztalat sok embert elrettent az új keretrendszer használatától vagy annak elfogadásától, és nagyon kevés keretrendszer tesz jó munkát az új felhasználók megsegítésében ezen a kezdeti akadályon.
A PHP-ben vannak olyan keretrendszereink is, amelyek nem igazán olyan keretek, ahogyan én szoktam használni a szót. Van néhány kedves alkatrész-keretünk; könyvtárak gyűjteményei, amelyek tetszés szerint használhatók és szépen játszanak együtt, például a Zeta Components (korábban eZ Components) és a Symfony Components (láttad már az oldalukat? Elnyerik a legjobb műalkotás díját!). Ezek közül a legjobb és a legtöbbet alátámasztott természetesen a PHP saját PEAR és PECL kínálata - ezek valahogy elfelejtődnek a keretek e bátor új világában.
Mikrokeretek
A mikrokeretek a PHP kialakulóban lévő trendjei; ezek rendkívül könnyű ajánlatok, amelyek csak segítenek a dolgok gyorsabb összeragasztásában. Jó példa erre a Slim, amely nagyon gyorsan és egyszerűen használható, és megérti a RESTful fogalmakat. Az „útvonalak” ötletén alapul, amelyek URL-minták. Regisztrál egy útvonalat, és visszahívást kezdeményez, amelyet meg kell hívni, amikor az URL-t kéri.
A legtöbb PHP fejlesztő elfogad egy keretrendszert, és ragaszkodik hozzá, különben használhatja az egyiket a munkahelyén, a másikat pedig hobbi vagy nyílt forráskódú projektjeihez. Kevés a konszenzus a „legjobb” keretrendszerrel kapcsolatban, így mindenki csak ragaszkodik ahhoz, amit tud, és ennek eredményeként hatalmas számú keretrendszer párhuzamosan fejlődik! Szeretem, ha van egy válogatás, de megemlítettem, hogy mind ugyanolyan rosszak, mint egymás?
Ha ismeri a Zend Framework-et, akkor végül leírja magát Zend Framework fejlesztőként; akkor nem lenne kényelmes egy másik keretrendszerben írni, amíg esélye sincs megismerkedni vele, és valószínűleg nem emlékszik a dolgok sok nyers PHP-funkciójára, ha nem használja őket gyakran. Ez az ötlet, hogy keretrendszer-specifikus fejlesztőkké váltunk, és csak az absztrakció rétegein dolgozunk, kissé furcsa a PHP számára. Végül is ez a nyelv "a webes probléma megoldására". C nyelven íródott, és önmagában is gyors, könnyű nyelv ... feltéve, hogy nem várja meg, hogy egy nagy keretrendszer bootstrap folyamata elinduljon! Ebből az összefüggésből került elő a MicroPHP kiáltvány, amelyet egy olyan ember írt, akit Funkatronnak hívunk (bár a neve valóban Ed Finkler). Ez egy sor kijelentés, miszerint rendben van egy sor átjárható kis modul felépítése, hogy a nagyobb nem jobb, és hogy valóban túl rövid az élet a Java számára - még akkor is, ha PHP-ben írják.
