Obsah
Spýtajte sa ma, ktorý rámec mám použiť, a pravdepodobne budem mať nevrlý okamih starej ženy a poviem ti, že všetky rámce sú navzájom také zlé. Čo neznamená, že sú všetky zlé, presne tak, ale v PHP máme nepredstaviteľne veľké množstvo rámcov (zvyčajne sa uvádza ako N + 1, kde N je počet vývojárov PHP na svete) a všetky pravdepodobne dávali zmysel osobe, ktorá ich vymyslela.
Výber rámcov je pravdepodobne lepší ako pokus o použitie iba jedného rámca bez ohľadu na to, čo konkrétne ste sa pokúšali vytvoriť, pretože je to ten „najlepší“ (bez ohľadu na mieru „najlepších“). Tento výber rámcových ponúk znamená, že si môžete vybrať niečo, čo zodpovedá potrebám projektu, a môže to byť dokonca zdokumentované. Rámečky na akejkoľvek platforme sú skutočne tu, aby poskytovali štruktúru, opakovane použiteľné moduly a knižnice, a všeobecne sa vyhýbajú všetkým nudným a opakujúcim sa úlohám súvisiacim s budovaním rovnakej funkčnosti stále dokola. Napríklad pri vytváraní CMS by mi malo niečo spracovať a overiť polia formulárov; ak to nechám na svoje vlastné zariadenia, môže mi uniknúť niečo dôležité a oveľa radšej by som urobil prvky každého projektu, ktoré sú rôzne, skôr ako tie, ktoré sú zakaždým rovnaké!
Full-stack rámce
Full-stack rámce, ako napríklad Zend Framework, môžu byť pre vývojárov príjemným miestom na začatie bez veľkého množstva skúseností s architektúrou. Poskytuje dobrú štruktúru na zavesenie novej aplikácie a okolo nej je dobrý „ekosystém“ - veľa kníh, návodov a primeranej dokumentácie. Ak sa pokúšate vytvoriť veľkú aplikáciu, ktorú bude udržiavať veľa ľudí, potom bude pravdepodobne populárny komplexný rámec dobrou voľbou, pretože bude vyžadovať značnú štruktúru a bude dobre známy a pochopený.
Mať štruktúru na pomoc pri odlúčení je vždy dobré; na začiatku svojej kariéry som s niektorými pracoval veľmi juniorskí vývojári a pokúsili sa ich naučiť model MVC (Model View Controller), ktorý bol v tom čase relatívne nový. Rozhodli sme sa použiť Smarty vo vrstve zobrazenia; čiastočne preto, aby návrhári mohli ľahšie pracovať so šablónami, a čiastočne tak, že keď niekto prišiel za môj stôl a povedal „ako urobím X so Smarty?“ Mohol by som povedať „nerobte X v zornom poli!“ (deväťkrát z 10, to bola odpoveď). Mať rámce nám pomáha nájsť rovnaké oddelenie v iných častiach našej aplikácie. Mnoho z nich podporuje integráciu proti šablónovej vrstve, ako je Smarty alebo môj nový obľúbený Twig, aby ste si mohli tieto nástroje vziať so sebou podľa toho, aký rámec si vyberiete.
Zľahčite záťaž
Existuje veľa ľahších frameworkov ako Zend Framework, napríklad s CodeIgniter pracujem dosť. Je rovnako komplexný a robustný ako Zend Framework? Nie, nie je. Ale ako pomocný rámec, ktorý umožňuje rýchle vytvorenie aplikácie, je to užitočné. Všeobecne je možné ľahšie sa zorientovať v rámci s menej „pomocnými“ funkciami, pretože je oveľa zrejmejšie, ako jednotlivé časti ladia. V neznámom rámci (pre mňa je to skoro všetko) sú to práve automatizované bity, s ktorými je ťažké pracovať a ladiť ich.
Tento pocit „straty v novom rámci“ je nevyhnutný a úplne frustrujúci; aj skúsený vývojár sa cíti ako nováčik, keď nevie, ako niečo funguje. Ak máte naozaj smolu, vybrali ste si rámec, ktorého kanál IRC vám povie, že ste tiež idiot! Je to táto veľmi negatívna počiatočná skúsenosť, ktorá na prvom mieste odradí veľa ľudí od používania nového rámca alebo jeho zavedenia, a len veľmi málo rámcov odvádza dobrú prácu tým, že pomáha novým používateľom v tejto počiatočnej prekážke.
V PHP máme aj niektoré rámce, ktoré v skutočnosti nie sú rámcami tak, ako obvykle používam toto slovo. Máme niekoľko krásnych komponentných rámcov; zbierky knižníc určených na použitie podľa ľubovôle a na pekné spoločné hranie, ako sú napríklad Zeta Components (predtým eZ Components) a Symfony Components (videli ste ich stránky? Získali cenu za najlepšie umelecké diela!). Najlepšie a najviac podceňované z nich sú samozrejme vlastné ponuky PEAR a PECL v PHP - nejako sa to zabudne v tomto odvážnom novom svete rámcov.
Mikrorámce
Mikrorámce sú v PHP novým trendom; toto sú mimoriadne ľahké ponuky, ktoré vám pomôžu rýchlejšie spojiť veci. Dobrým príkladom je Slim, ktorý je veľmi rýchly a ľahko použiteľný a rozumie konceptom RESTful. Je to založené na myšlienke „trás“, čo sú vzory adries URL. Zaregistrujete trasu a zavoláte spätné volanie, ktoré by sa malo vyvolať, keď sa požaduje táto adresa URL.
Väčšina vývojárov PHP si osvojuje rámec a drží sa ho, alebo môže jeden použiť v práci a druhý na svoje hobby alebo open source projekty. Panuje malá zhoda v otázke „najlepšieho“ rámca, ktorý treba použiť, takže sa každý len drží toho, čo vie, a výsledkom je paralelný vývoj veľkého množstva rámcov! Rád mám na výber, ale spomenul som, že sú všetky rovnako zlé ako jeden druhému?
Ak poznáte Zend Framework, nakoniec sa označujete za vývojára Zend Framework; nebolo by vám pohodlné písať v inom rámci, kým by ste nemali možnosť sa s tým vyrovnať, a pravdepodobne si nepamätáte veľa nespracovaných funkcií PHP, ak ich nepoužívate často. Táto myšlienka, že sme sa stali vývojármi špecifickými pre daný rámec, pracujeme iba na vrstvách abstrakcie, je pre PHP trochu zvláštna. Koniec koncov, toto je jazyk „na vyriešenie problému s webom“. Je napísaný v jazyku C a je sám o sebe rýchlym a ľahkým jazykom ... za predpokladu, že nečakáte na spustenie veľkého procesu bootstrapu rámca! Z tohto kontextu vyšiel Manifest MicroPHP, ktorý napísal človek, ktorému hovoríme Funkatron (aj keď sa skutočne volá Ed Finkler). Je to séria vyhlásení, ktoré hovoria, že je v poriadku stavať množstvo interoperabilných malých modulov, že väčšie nie sú lepšie a že v skutočnosti je život Java príliš krátky - aj keď je napísaný v PHP.
