Obsah
Zeptejte se mě, jaký rámec použít, a pravděpodobně budu mít nevrlý okamžik staré ženy a řeknu vám, že všechny rámce jsou stejně špatné jako ostatní. Což neznamená, že jsou všechny špatné, přesně, ale v PHP máme nepředstavitelně velké množství rámců (obvykle uváděných jako N + 1, kde N je počet vývojářů PHP na světě) a všichni pravděpodobně dávali smysl osobě, která je vynalezla.
Mít výběr rámců je pravděpodobně lepší, než se snažit použít pouze jeden rámec, bez ohledu na to, o co přesně jste se pokoušeli stavět, protože je to ten „nejlepší“ (bez ohledu na „nejlepší“). Tento výběr nabídek rámce znamená, že si můžete vybrat něco, co splňuje potřeby projektu, a to může být dokonce zdokumentováno. Rámečky na jakékoli platformě jsou skutečně k tomu, aby poskytovaly strukturu, opakovaně použitelné moduly a knihovny a obecně se vyhnuly všem nudným a opakujícím se úkolům spojeným s budováním stejné funkce znovu a znovu. Například při vytváření CMS by pro mě mělo něco zpracovat a ověřit pole formuláře; pokud to nechám na svá vlastní zařízení, může mi uniknout něco důležitého a mnohem raději bych udělal prvky každého projektu, které jsou odlišný, spíše než ty, které jsou pokaždé stejné!
Full-stack rámce
Full-stack frameworks, jako je Zend Framework, může být pro vývojáře příjemným místem, kde začít, aniž by měl spoustu zkušeností s architekturou. Poskytuje dobrou strukturu pro zavěšení nové aplikace a je kolem ní dobrý „ekosystém“ - spousta knih, tutoriálů a také nějaká rozumná dokumentace. Pokud se pokoušíte vytvořit velkou aplikaci, kterou bude udržovat spousta lidí, pak bude populární a komplexní rámec pravděpodobně dobrou volbou, protože bude diktovat poměrně velkou strukturu a bude dobře známý a srozumitelný.
Mít strukturu, která vám pomůže s odloučením, je vždy dobrá; na začátku své kariéry jsem s některými pracoval velmi mladší vývojáři a pokusili se je naučit vzor MVC (Model View Controller), který byl v té době relativně nový. Rozhodli jsme se použít Smarty ve vrstvě zobrazení; částečně proto, aby designéři mohli snáze pracovat se šablonami, a částečně proto, že když někdo přišel ke mně a řekl: „jak to udělám X se Smarty?“ Mohl bych říct „nedělej X v pohledu!“ (devětkrát z 10, to byla odpověď). Mít rámce nám pomáhá najít stejné oddělení v jiných částech naší aplikace. Mnoho z nich podporuje integraci proti templatingové vrstvě, jako je Smarty nebo můj nový oblíbený Twig, takže si tyto nástroje můžete vzít s sebou, jakýkoli rámec si vyberete.
Odlehčete náklad
Existuje spousta lehčích frameworků než Zend Framework, například s CodeIgniter docela dobře pracuji. Je stejně komplexní a robustní jako Zend Framework? Ne, není. Ale jako pomocný rámec umožňující rychlé vytváření aplikace je to užitečné. Obecně platí, že rámce s méně „pomocnými“ funkcemi se dají snáze zorientovat, protože je mnohem zřetelnější, jak jednotlivé části spolu ladí. V neznámém rámci (pro mě je to skoro všechno) jsou to právě automagické bity, díky nimž je těžké pracovat a ladit.
Ten pocit „ztráty v novém rámci“ je nevyhnutelný a naprosto frustrující; i zkušený vývojář se cítí jako nováček, když neví, jak něco funguje. Pokud máte opravdu smůlu, vybrali jste si rámec, jehož kanál IRC vám řekne, že jste také idiot! Je to tato velmi negativní počáteční zkušenost, která na prvním místě odradí mnoho lidí od používání nového rámce nebo jeho přijetí a jen velmi málo rámců odvede dobrou práci a pomůže novým uživatelům překonat počáteční překážku.
V PHP máme také některé rámce, které ve skutečnosti nejsou rámci tak, jak to slovo obvykle používám. Máme několik krásných komponentních rámců; sbírky knihoven, které jsou určeny k použití podle libosti a k pěknému společnému hraní, například Zeta Components (dříve eZ Components) a Symfony Components (viděli jste jejich web? Získali cenu za nejlepší umělecká díla!). Nejlepší a nejpodceňovanější z nich je samozřejmě vlastní nabídka PEAR a PECL v PHP - v tomto odvážném novém světě rámců to nějak zapomene.
Mikroframeworks
Microframeworks jsou v PHP novým trendem; jedná se o mimořádně lehkou nabídku, která vám pomůže rychleji spojit věci. Dobrým příkladem je Slim, který je velmi rychlý a snadno použitelný a rozumí konceptům RESTful. Je založen na myšlence „tras“, což jsou vzory URL. Zaregistrujete trasu a dáte zpětné volání, které by mělo být vyvoláno, když je požadována tato adresa URL.
Většina vývojářů PHP přijme rámec a bude se ho držet, nebo mohou jeden použít v práci a druhý pro své hobby nebo open source projekty. Existuje jen malá shoda ohledně „nejlepšího“ rámce, který se má použít, takže se každý jen drží toho, co zná, a výsledkem je paralelní vývoj obrovského počtu rámců! Ráda mám na výběr, ale zmínila jsem se, že jsou všechny stejně špatné jako ostatní?
Pokud znáte Zend Framework, pak sami sebe popisujete jako vývojáře Zend Framework; nebylo by vám příjemné psát v jiném rámci, dokud byste neměli šanci se s tím vyrovnat, a pravděpodobně si nepamatujete mnoho surových funkcí PHP pro věci, pokud je nepoužíváte často. Tato myšlenka, že jsme se stali vývojáři specifickými pro daný rámec, pracujeme pouze na vrstvách abstrakce, je pro PHP trochu divná. Koneckonců, toto je jazyk „k vyřešení problému s webem“. Je napsán v jazyce C a je to rychlý a lehký jazyk sám o sobě ... za předpokladu, že nebudete čekat na spuštění velkého rámcového bootstrapového procesu! Z tohoto kontextu vyplynul Manifest MicroPHP, napsaný člověkem, kterému říkáme Funkatron (i když se opravdu jmenuje Ed Finkler). Je to řada prohlášení, která říkají, že je v pořádku stavět řadu interoperabilních malých modulů, že větší nejsou lepší a že ve skutečnosti je život pro Javu příliš krátký - i když je napsán v PHP.
