Přeskočit na hlavní obsah

Letmý pohled na php frameworky Zend, CakePHP a Prado

Tento článek vyšel původně na blogu derhaa.com, který jsem však zrušil.

Abstrakt

Tento článek je předvojem seriálu o Zend Framework(u) – dále je tu velmi stručný rozbor,  jak sem nahlédl pod pokličku dalších dvou frameworků –  CakePHP (CP) a Prado (PD).  Mimochodem se zde stručně dozvíme jak frameworky pracují a soupis funkčností, kterými se od sebe odlišují. Cílem článku je povrchně seznámit čtenáře se třemi PHP frameworky, které se staly předmětem mého zájmu – v čem napsat středně veliký projekt.

 

Idea

Když jsem přemýšlel v čem napíšu svůj první větší počin, tj. aplikace typu HRMS, jehož dalším cílem bude nad shromážděnými daty provádět specifické analýzy/statistiky související se sportovní tématikou. Předpokládal jsem, že to nebude malý projekt, který lze napsat na koleni, ale budu potřebovat sofistikovanější nástroje pro práci s databází (ORM),  propracovanější návrh doménového modelu, následné rozdělení aplikace na logické celky – vrstvy, dále pak komfortnější uživatelské prostředí postavené na widget(ech), možnosti psát jednotkové a integrační testy a nástroje pro kontinuální integraci (např. Hudson).
Do této doby jsem nic z těchto nástrojů, přístupů, návrhů , popř. postupů vůbec nepotřeboval. Aplikace byly natolik malé, že byl prostě nesmysl nad nimi stavět nebesa – prostě ala kanón na vrabce.  Dalším nemalou motivací pro mne bylo naprosto neznámé prostředí, potřeboval sem ve velmi krátké době nastudovat technologie, které mi v co nejkratším čase poskytnout možnost implementovat stanovené cíle.

Vybírám technologie

Platforma byla předem známa – Php , MySQL a na UserInterface bude řešen via widget-based javascriptovým frameworkem. Konečný výčet php frameworků je stanoven na CakePHP, Prado a Zend Framework.Všechny mají vynikající dokumentaci (CakePHP má dokonce lokalizovaný manuál), a lze s nadsázkou říct, že pomineme-li konfiguraci vývojového prostředí, můžete prostě začít programovat s veškerou parádou. Tyto frameworky jsou excelentní ukázkou,  jak lze v PHP objektově programovat, a po načtení životního cyklu request-response, lze velmi rychle a elegantně začít implementovat.
Všechny frameworky jsou vyrovnány, co se týče nabídky vlastností, což můžete porovnat v přehledné tabulce, kterou naleznete na adrese – srovnání php frameworků. Všechny se snaží o transparentní návrh jednotlivých aplikačních vrstev – jednotlivé oddělení logických celků (service, dao, orm, database). Dále nabízejí transakční zpracování, validátory pro své UI componenty/helpery, podporu pro RPC,

Rozdíly

  1. implementace rozdílných přístupů do datového modelu (DAO)
  2. životní cyklus request/response (PRADO se podstatně odlišuje)
  3. nativní podpora javascriptových knihoven
ad 1. V DAO vrstvě jsou rozdíly:
    • ZF neimplementuje ORM, ale implementuje oddělené low-level přístupy za pomocí Table-Data-Gateway a Row-Data-Gateway, a  jako dao objekt zde figuruje tzv. DataMapper.
    • CakePHP i Prado implementuji ORM (ActiveRecord), CakePHP v rámci třídy BehaviourCollection, Prado v rámci třídy TActiveRecord
    Lze říct, že rozdíly v implementaci nemění nic na tom, že oba přístupy splňují v podstatě totéž, a to že získat data z databáze bez znalosti databázové platformy. Hlubší analýza bude součástí dalšího pokračování seriálu, konkrétně implementace v ZF.
    ad 2. Další rozdíl je v tom, jak PRADO implementuje zpracování životního cyklu request-response a skladbu objektů v rámci MVC konceptu, ale to popisuji později v tomto článku.
    ad 3.Co se týče integrace s existujícími javascriptovými knihovnami, i zde se situace liší.  ZF začlenil dva javascriptové frameworky jQuery (jQueryUI) a Dojo (Dijit, Dojox). Co se týče CakePHP a Prado pro změnu knihovny Prototype a Script.aculo.us. Není samozřejmě zakázáno používat jiné javascriptové frameworky.

    Rapid application development

    Mají další společnou vlastnost – uplatňují metodiku RAD, která má za cíl urychlit vývoj aplikace. V tomto případě je tato metodika uplatňována pomocí nástroje (commandline toolu), který vývojáři napomáhá sestavit projekt a vytvářet další logické celky/struktury, anebo samostatné objekty, které jsou součástí životního cyklu daného frameworku.
    Vývojář sice musí znát filesystém frameworku, a vědět jak framework funguje, ale není nucen struktury/objekty manuálně vytvářet – k tomu, jsou předurčeny tyto commandline nástroje, které dané celky sestaví (aplikační strukturu,  jednotlivé controllery, action, moduly, view, dbtable objekty) do filesystémové struktury, popř. vygeneruje skelety jednotlivých objektů, např. typu Controller, Action, Modul nebo View, DbTable či Layout.

    Life cycle

    Všechny vycházejí z podobného konceptu, že životní cyklus request-response je silně orientován či postaven na MVC návrhovém vzoru, a od toho se odvíjí i filesystémová struktura projektu, dokonce i konvence pojmenování samotných objektů (tříd), které se bezprostředně životního cyklu frameworku zúčastňují.  Je to sice zavazující, ale logické a velmi sympatické, a jak se později ukázalo, když jsem pronikal do filozofie životního cyklu u jednotlivých frameworků.
    V podstatě dojde k requestu na webový server, kde je URL rozparsována, aby se namapoval Controller objekt a Akce, která daný požadavek obslouží. Tato konstrukce je vlastně návrhový vzor Front Controller, parsování URL má na starost objekt Dispatcher (CakePHP), Router (ZF) nebo THttpRequest (Prado).  Controller objekt má dále pre/post callbacky, které nám dovolují implementovat dodatečnou logiku před/po samotným zpracováním requestu.

    Obr. 1 Vývojový diagram představující typický CakePHP požadavek

    Samotný proces zpracování requestu má na starost konkrétní Action daného Controlleru, která je povětšinou metodou samotného Controlleru. V tento moment je požadavek ve frameworku zpracován a systém (vývojář) je schopen rozhodnout, jak dále oslovit Model.  O tom jak pracuje s MVC v aplikaci lze opět s nadsázkou říct, že vás frameworky poveden a ukázkově představí, jak to má v praxi vypadat.


    Obr. 2 Vývojový diagrame Zend Framework požadavku

    Když sem začínal s MVC, tak sem ze začátku nevěděl,  kde mám implementovat svůj kód, neustále se mi míchal kód frameworku s mým a měl sem zpočátku problém tyto dvě věci oddělit. A zvolil sem taktiku, že když jsem nevěděl, kam se svým aplikačním kód, psal sem to do Modelu. A nebylo to tak bolestné rozhodnutí, když jsem při review kódu zjistil, že cca 90% kódu bylo správně umístěno v Modelu. Jak sem psal výše, framework vás během jeho používání navede a „donutí“ přemýšlet o čistém návrhu MVC.

     

    Obr. 3 UML diagram PRADO požadavku

    CakePHP a Zend Framework jsou si v mnoha ohledech při práci s MVC velmi podobní. PRADO se však velmi liší, jeho implementace je postavena tzv. component-based a event-driven-development přístupu, má zcela jinou terminologii, strukturu a zpracování životního cyklu request-response.  Základem je objekt Page, kterou lze chápat jako Controller, v jeho řežii je kompletní správa životního cyklu. View je implementováno za pomocí tzv. Templates, kterou musí mít každý objekt Page. Template není nic jiného než skladba nezávislých Component (aka HTML tagu nebo Widgetů), které spolu interagují za pomocí událostí. Model není přesně specifikován, a nemá vlastní umístění ve struktuře projektu, tak jak jej mají CP a ZF. Nicméně dle slov autorů PRADO – MVC vzor vyplývá mimochodem, právě oddělením Controlleru a View – Templates.

    Závěr

    Velmi kvalitně zdokumentované, komunitní servery, široká základna uživatelů, diskusní fóra dělají z těchto frameworků jako dobrou volbu pro Váš projekt. Já jsem si nakonec dal přednost ZF, je robustnější a nabízí jQuery, které mi nebylo cizí, a zároveň Dojo framework, který sem si chtěl vyzkoušet. Dále po zkušenosti s CakePHP mohu říct, že nepůjdu-li do hloubky, mohu říct, že když se naučím ZF, tak přechod na CakePHP bude mávnutím proutku. PRADO svou odlišností a přístupem mě zaujal natolik, že po nastudování Zend Frameworku, bych se k němu chtěl vrátit a zkusit si v něm napsat nějaký projekt.

    Zajímavé odkazy

    Štítky:
    Místo: 397 01 Písek, Česká republika

    Komentáře

    Okomentovat

    Populární příspěvky z tohoto blogu

    Zend_Tool - Cannot redeclare class Zend_Loader

    V mém případě, když jsem zadal následující příkaz: zf create module admin V konsoli se objevila následujicí hláška Cannot redeclare class Zend_Loader in path/to/library/Zend/Loader on line 31 Řešení je jednochuché - Nakopírujte soubory zf.bat a zf.php z adresáře %ZEND_FRAMEWORK_DIR%/bin do adresáře %PHP_HOME% . V případě, že chcete vědět více – mkrněte na oficiální dokumentaci Zend_Tool .
    Okomentovat
    Další informace

    PHP a Zend Framework autoloading

    Úvod V příspěvku se zmíním o způsobu a správě „importů“ (tzv. autoloading) php souborů v samotném PHP a poté se dozvíme, jak autoloading php souborů řeší Zend Framework. Autoloading v PHP Správa importů v PHP Jak "importovat" v PHP soubory Jak funguje mechanismus importů v PHP Autoloading v Zend Framework Autoloading v PHP Základem při psaní aplikací v PHP je nutné si uvědomit, jak funguje tzv. autoloading php souborů. V PHP neexistují importy jako je známe např. z Java. Když například potřebujete konstruhovat třídu jejíž definice je v jiném souboru – je nutné si tento soubor za pomocí konstrukce require nebo require_once ( include , include_once ) “naimportovat“ do svého souboru (předpokladem, je že soubory jsou umístěné na include_path ). Dalším řešením je překrýt funkci autoload . Správa importů v PHP Správa “importů” souborů v php mi přijde neštastná. Jedná se do jisté míry o problém, alespoň pro mne – jsem vývojářem v Java , kde tento mechanismus je zajišt...
    Okomentovat
    Další informace