Přejít k navigační liště

Zdroják » PHP » ORM frameworky pro PHP5: Obecný úvod

ORM frameworky pro PHP5: Obecný úvod

Články PHP, Různé

ORM (Object Relational Mapping), tedy metoda mapování relační databáze na objekty, má podporu ve všech moderních programovacích jazycích. S příchodem PHP5 a ustálením koncepce objektového programování začal také vývoj ORM frameworků pro PHP. V tomto třídílném miniseriálu se seznámíme se dvěma zástupci návrhového vzoru Active Record a ukážeme si přínosy jejich nasazení v reálných situacích.

Významnějších ORM frameworků pro PHP5 je v současnosti několik desítek. Většina je založena na návrhovém vzoru Active Record, kdy objekt reprezentuje řádek tabulky a obstarává základní operace s řádkem: vytvoř, aktualizuj a smaž (v angličtině zkratka CRUD, která bude i dále použita jako označení základních operací). Frameworky je možné dělit podle počtu funkcí, které nabízejí programátorovi.

Může se jednat o minimalistický přístup, kdy je poskytnuta abstraktní databázová vrstva pro jednotný přístup k různým databázovým systémům, základní operace CRUD a případně další funkce pro rychlé získání záznamu (např. podle primárního klíče). Komplexní přístup kromě výše uvedených funkcí přidává další nadstavby, které usnadní vývoj rozsáhlejšího nebo modulárního systému. Frameworky Doctrine a Propel jsou zástupci komplexních frameworků a v následujících článcích se seznámíme s jejich přínosem v reálných projektech.

Před výběrem frameworku je potřeba určit, jaké jsou nároky na vyvíjenou aplikaci. Frameworky Doctrine i Propel jsou nejvhodnější pro aplikace splňující alespoň jednu z těchto podmínek:

  • Aplikace s očekávaným nasazením vícečlenného vývojářského týmu a dlouhodobým vývojem.
  • Modulární aplikace, např. internetový obchod nebo redakční systém, u které je potřeba mít možnost připojovat jednotlivé nezávislé moduly.
  • Kritická aplikace s nutností zajištění kvality kódu.

Výhody použití ORM frameworku

Přínos frameworků klesá se snižující se velikostí aplikace a pro jednoduchou stránku bez redakčního systému a s několika tabulkami ztrácí jejich nasazení smysl. ORM framework vhodně doplňuje MVC (Model View Controler) framework a unit testy, což jsou dobré základy pro vývoj robustních webových aplikací. Pojďme se podrobněji pozastavit nad obecnými výhodami nasazení ORM frameworku:

  • Abstraktní databázová vrstva

    Ačkoliv PHP standardně nabízí PDO pro univerzální přístup k databázovým systémům, stále zůstává nejednotný zápis SQL příkazů (např. omezení pro výběr prvních 10 záznamů z dotazu je různý pro MySQL a MSSQL). Doctrine i Propel nabízí zápis databázových dotazů, který je přenositelný mezi různými databázemi a to i včetně dotazů pro tvorbu nebo aktualizaci struktury tabulek.

  • Zapouzdření do objektů

    Možnost zapouzdřit související funkce přímo do objektu reprezentujícího řádek tabulky velice usnadní čitelnost a testovatelnost kódu. Většina ORM frameworků nabízí předgenerované třídy pro každou tabulku databáze se základními metodami CRUD, gettery a settery. Tyto objekty je možné dále rozšiřovat, aniž by došlo při dalším generování základních tříd k jejich nežádoucímu přepsání.

  • Unit testy

    ORM frameworky mají v mnoha případech zajištěnu kvalitu kódu pomocí unit testů a jsou napsány tak, aby bylo možné testovat i metody v rozšířených třídách. Pokud ORM framework podporuje databáze s paměťovým úložištěm (např. SQLite memory), jsou unit testy velice rychlé a je zajištěno izolované prostředí pro každý běh testu.

  • Validátory hodnot

    Hodnoty objektu (a tedy i záznamu tabulky) jsou nastavovány přes vygenerované gettery a settery nebo přes magické metody představené v PHP5. Proto je možné hodnoty před nastavením validovat případně vyčistit od nebezpečných znaků. ORM frameworky, které jsou generované z databázové struktury nebo popisných souborů (XML, YML nebo anotace), samy vygenerují základní validátory na povinné hodnoty a datové typy proměnných třídy.

  • CRUD generátor

    Základní operace se záznamy jsou hlavním účelem administračního systému. ORM framework je schopen na základě definice databázových objektů vytvořit uživatelské rozhraní pro tyto operace včetně validátorů a výpisů s filtrací. Vygenerované rozhraní je možné dále rozšiřovat a CRUD generátor může úspěšně fungovat jako základ rozsáhlých administračních systémů.

Nevýhody ORM frameworků

  • Učící křivka

    Největší nevýhodou ORM frameworku je nutnost naučit se framework používat. Čím více je framework komplexní, tím více dokumentace je potřeba zpracovat. Při výběru vhodného frameworku je nutné si předem ověřit dostupnost kvalitní dokumentace a zda existuje funkční komunita, která bude schopna podat pomocnou ruku v okamžiku, kdy se dostaneme mimo pole pokryté dokumentací.

  • Riziko výběru špatného ORM frameworku

    Jak již bylo uvedeno výše, ORM frameworků pro PHP je mnoho a výběr toho správného je komplikovaný. Musíme si uvědomit, jaké funkce očekáváme a zhruba jaký objem dat bude cílová aplikace obsahovat. ORM frameworky jsou poměrně mladé a stále se intenzivně vyvíjejí a přichází s novými funkcemi, proto je důležité vybrat framework se silnou vývojářskou komunitou a dostatečně otevřenou licencí, aby nebyly překážky v dalším vývoji. Dále je dobré předem zjistit, jak framework pracuje s většími objemy dat a zda nenarazíme na paměťové limity.

  • Paměťová a procesorová náročnost

    ORM framework přidává do aplikace další vrstvu a v případě větších frameworků je vyšší paměťová náročnost znatelná. Při mapování záznamu tabulky na objekt dochází k takzvané hydrataci (angl. hydrate), každý objekt zabírá své místo v paměti a při načtení většího počtu záznamů můžeme narazit na paměťový limit pro běh jednoho skriptu. Navíc až do PHP 5.3 byly problémy s uvolňováním paměti, zejména u objektů s cyklickými vazbami.

    Nejedná se o nepřekonatelný problém, jen je vždy nutné s paměťovou náročností počítat. Větší množství pasivní záznamů (např. výpis položek) je lepší načíst do proměnné typu pole a pouze položky, na kterých budou volány funkce, načítat do objektů.

Chcete se naučit o PHP víc?

Akademie Root.cz pořádá školení Kurz programování v PHP5. Jednodenní kurz programování v PHP 5 je určen všem webovým vývojářům, kteří se chtějí do hloubky seznámit a sžít s programovacím jazykem PHP ve verzi 5. První část kurzu je zaměřena na nový objektový model se všemi jeho vlastnostmi, ošetření chyb pomocí výjimek a efektivní využití těchto konceptů. Druhá část je zaměřena na nové knihovny PHP 5, především pro práci s databázemi, XML a objekty. Pozornost je věnována i zajištění kompatibility s PHP 4, přechodu z této verze a výhledu na PHP 6. Máte zájem o jiné školení? Napište nám!

ORM frameworky Doctrine a Propel

V dalším dílu článku se podrobněji seznámíme s frameworkem Doctrine. Vlastnosti popsané pro tento framework platí s menšími odchylkami i pro framework Propel. Tyto frameworky byly vybrány, protože se jedná o nejčastěji používané komplexní ORM frameworky. Projekt Propel započal v roce 2005, bohužel ale zhruba od roku 2007 došlo ke zpomalení vývoje a uživatelé zůstali dlouho s poslední stabilní verzí 1.2, která obsahovala ovšem několik nepříjemných vlastností a chyb. V roce 2009 došlo k výměně hlavního vývojáře a opětovnému oživení projektu. Propel je nyní ve verzi 1.4.

Vrstvy ORM frameworku Doctrine

Od roku 2007 byl vyvíjen projekt Doctrine, který zvolil trochu jiný přístup než Propel a přinesl lepší výkon a nové zajímavé funkce. První stabilní verze projektu Doctrine byla představena 1. září 2008. Lze říci, že koncepce zvolená v případě Doctrine je konzistentnější a čistota kódu je mnohem větší (díky stovkám unit testů je vyšší i kvalita kódu). V současnosti probíhá vývoj na verzi Doctrine 2, která naplno využívá možností PHP 5.3 (jmenné prostory, anonymní funkce, vylepšený garbage collector a anotace). Za Doctrine stojí významný MVC framework Symfony a silná vývojářská i uživatelská komunita.

Komentáře

Subscribe
Upozornit na
guest
33 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jiří Knesl

„ORM (Object Relational Mapping), tedy metoda mapování relační databáze na objekty“

Tak to přeci není. ORM není mapování relace → objekty, ale mapování objekty → relace. Může to znít jako triviální hloupost, ale v reálu je to propastný rozdíl. Už v tom, že mapovat relace na objekty je v objektovém programování naprosto k ničemu.

Jiří Knesl

A když už jsem se tak rozjel. Active Record právě není ORM.

V objektové analýze udělám class diagram (a nekoukám na relační schéma), v analýze databáze udělám relační schéma (a nekoukám na class diagram) a ORM je pak něco, co to navzájem spojí. Něčeho takového není Active Record nikdy schopen (jedině by to shodou náhod byly tyto modely skutečně 1:1, což se mi ještě nikdy nestalo).

Mastodont

Nechci se hádat, protože definic je víc, ale Fowler výslovně uvádí AR jako jeden ze vzorů ORM …

frantisek.troster

Dobrý den,

děkuji za Váš názor. Souhlasím s Vámi, že ta věta je nepřesná a možná i zavádějící. Jak už to u vět, které zjednodušují něco komplexního, zákonitě bývá. To se ostatně ukazuje i na Vaší větě, kterou mi oponujete. ORM je něco nesměrového a měl jsem správně napsat, že se jedná o techniku propojení relačních databází a objektů. Pokud postupuji od ER modelu, ze kterého vygeneruji objekty (přístup zmiňovaných ORM frameworků), pak mapuji relační databázi na objekty. Pokud naopak vytvořím class diagram, na základě něho pak objekty a z těch vygeneruji databázi, pak mapuji objekty na relační databázi.

Mapování relací (možná jste chybně zaregistroval, že nepíšu o relacích ale relačních databázích) na objekty pochopitelně smysl má a je to jedna z velkých výhod ORM. Relace se objektově zapisuje jako agregace. Tedy v ER zapíšu, že kontakt má n telefonních adres, 1:N relace. Objektově to pak zapíšu, že objekt kontakt obsahuje kolekci telefonních čísel.

Active Record samozřejmě je jeden z možných přístupů k ORM. Active Record je velice obecný návrhový vzor a opět velice zjednodušeně (tudíž opět nepřesně) říká, že řádek tabulky se „stará“ sám o sebe (obsahuje metody pro uložení do DB apod.). Nikde se nepíše, že Active Record musí/nemusí být 1:1 s relační databází. Oba mnou uváděné frameworky generují třídy, které jsou přesným obrazem relační databáze a tudíž je obecně zaměnitelné zda hovoříme o class diagramu (pokud ignoruji provázanost s dalšími objekty aplikace) těchto tříd nebo o ER modelu.

Jiří Knesl

Děkuji za odpověď.

ORM je skutečně propojení. Jde ale o tu logiku, já mám nějaký class diagram (který ale při převedení 1:1 do relací třeba poruší 3.NF, nebo způsobí velké zpomalení db) a ORM mi má umožnit programovat objektově a nevnímat, že existuje nějaká databáze (a že v té databázi je to z důvodů výkonu, čistoty nebo jiných uspořádáno úplně jinak).

„Pokud postupuji od ER modelu“ – to je právě to, co právě v prvních komentářích kritizuji (a od čeho třeba své studenty odrazuji, jak to jen jde). Objektová analýza a použití objektů se přeci nesmí přizpůsobovat tomu, že existuje ER diagram, že jsem použil relační, nebo stromovou nebo jinou databázi.

AR lze vytvořit z libovolného řádku SQL resultu (a tento může být opravdu z více tabulek/views), pokud je možné potom tento řádek upravit a znovu uložit (ze „select concat(jmeno, prijmeni) from users“ tedy například AR vytvořit nelze). Doctrine i Propel jsou ukázkami knihoven (nejsou to frameworky, framework je například Zend, Nette, CakePHP, Struts nebo .NET), které šly daleko za možnosti Active Recordu (různé pluginy jako versionable, localisable, blameable…).

„tudíž je obecně zaměnitelné zda hovoříme o class diagramu (pokud ignoruji provázanost s dalšími objekty aplikace) těchto tříd nebo o ER modelu“ – to je právě něco, za co by studenta každé slušné VŠ vyhodili od zkoušky. :)

frantisek.troster

Je přeci jedno, zda začnu projekt Class Diagramem neb ER modelem. Pokud pracuji čistě s AR je jedno zaměnitelné s druhým a mění se pouze notace. Nikde není psáno, že vývoj musí začínat objektovou analýzou. Ve vývoji software existuje tolik možných přístupů a nikdo nemůže říct, že jeho přístup je jediný správný. Zastávám názor, že na modelování má být použit nástroj, který je pro mě v dané situaci nejrychlejší a nejpřehlednější. Nemusím to obhajovat u zkoušky, protože měřítko správnosti mého názoru je to, zda projekt dovedu do konce nebo ne. Proto se prosím nebavme o tom, co má být správně podle příruček. Příručky znám, školou jsem si prošel a považuji ji za velice dobrý základ do praxe.

Nemyslím si, že správně navržený class diagram bude odporovat normálním formám, protože to jsou natolik obecná pravidla, která jsou dodržována automaticky „selským rozumem“.

Kam byste začlenil ORM frameworky/knihovny (nechápu rozdíl) Propel a Doctrine? Vycházejí z návrhového vzoru Active Record a jak píšu v článku, dotahují ho do velice komplexního řešení. To jestli mají pluginy je irelevantní.

jos

je to jen muj pocit, nebo používáte slovo relace ve smyslu „vztah mezi tabulkama“? z toho se mi dycky ježí chlupy.

Jan Tichý

„Tedy v ER zapíšu, že kontakt má n telefonních adres, 1:N relace.“
Asi by bylo dobré si nejdřív ujasnit terminologii, pod pojmem „relace“ se v relační algebře a potažmo pak i v relačních databázích rozhodně nemyslí vazby mezi tabulkami. „Relace“ je označení pro právě jednu tabulku.

Jiří Knesl

A kde? Já v Patterns of enterprise application architecture od Martina Fowlera nikde zmínku o tom, že by AR byl ORM, nenašel. Spíš právě naopak, tvrdí, že AR je dobrý jen pro velmi jednoduché projekty, sám AR kritizuje, že AR vyžaduje shodný objektový a relační model a že u větších projektů AR ztěžuje možnost refaktoringu.

Nerad bych vypadal, jako že mi AR nějak zvlášť vadí. U blogísku s 1 formulářem (nebo ultrajednoduché CMS) ho použiju taky. Tam mi zjevné porušení naprosto samozřejmé věci, tedy že class diagram a databázové schéma nemají NIC společného (a že mapovat je 1:1 je chyba) až tak nevadí.

U takových projektů platí „worse is better“ a čistota je obětována produktivitě. Ale prostě nemá smysl tvrdit, že AR je ukázkou ORM. AR je ukázkou, jak psát rychle a produktivně. :)

frantisek.troster

V knize Patterns of enterprise application architecture o Active Record hovoří a také tam uvádí, že má-li Active Record pattern fungovat správně, pak musí být 1:1 s Active Record objekty. Nezaregistroval jsem zmínku o tom, že by byl Active Record špatný, je naopak uvedeno několik případů, kdy je vhodnější než jiné přístupy. Nezaznamenal jsem možnost ztížení refaktoringu, refaktorizuju neustále a s Doctrine a unit testy velice bezpečně.

Možná jste s Active Record nepřišel více do styku a vycházíte pouze ze zkušenosti s napsáním nějaké jednodušší aplikace. Článek vychází z mých praktických zkušeností, ne z nějakého načítání dokumentace. Mohl jsem napsat o tom, že Active Record pattern je mrtvý a nepoužitelný. Ale není to pravda, Doctrine i Propel jsou hlavní ORM frameworky pro PHP, které jsou používané od Cake PHP přes Symfony až po Zend.

Jiří Knesl

Active Record jsem používal a používám už několik let (v Ruby on Rails ActiveRecord, CakePHP AppModel, Zend_Db_Table, generované třídy pro .NET, proprietární řešení) a právě fungoval dobře u malých projektů.

Pro ty větší (více lidí, několik měsíců/let práce a intenzivního refaktoringu a údržby) se vždy vyplatilo použít místo AR DataMapper nebo alespoň řešení za hranicí AR (a třeba Doctrine i Propel jsou velmi daleko za ActiveRecordem, jsou tedy pro obhajobu AR nevhodné).

Ad ty Patterns… – přečtěte si kapitolu „When to use it“, já mám za to, že Fowler tvrdí naprosto totéž, co já.

frantisek.troster

Active Record implementace, které uvádíte, mají odlišný přístup od Doctrine a Propel. Nemám s nimi žádné větší praktické zkušenosti, proto se k nim nemůžu vyjadřovat. Viz. příspěvek výše, nevím na základě čeho odmítáte, že Doctrine i Propel jsou zástupci AR. Dotahují celý koncept do velice komplexní podoby a umožňují efektivní propojení MVC a ORM frameworku.

Nemyslím si, že někde v článku píšu o Active Record jako o ideálním návrhovém vzoru. Pouze konstatuji, že Doctrine i Propel jsou zástupci tohoto návrhového vzoru a že většina PHP ORM frameworků z tohoto návrhového vzoru vychází. Až vyjde stabilní verze Doctrine 2 a bude tam použit perzistentní manažer, budu používat tuto knihovnu, protože vykazuje lepší parametry. Nemyslím si, že by ale byl AR v podání Doctrine 1 o moc horší, někdy se používá lépe, někdy hůře. Možnosti refaktorizace zůstávají stejné, přínos vidím v menší paměťové náročnosti mapovaných objektů.

smilelover

Me hrozne nesedi to, ze jsou CRUD metody primo na danych domenovych tridach. Z objektoveho pohledu je to IMHO prasarna, protoze struktura domeny ma reprezentovat modelovanou realitu a zodpovednost domenovych objektu typu Book, Person ci cokoliv jineho v zadnem pripade nema byt operace nad perzistenci (viz. napr JPA)… Teoreticky by ty tridy nemely vubec vedet, ze jsou pouzivany s ORM (to je ovsem v realu dost tezke, i to JPA tam ma alespon ty anotace).

Z tech dvou zminenych mam zkusenost s Propelem na relativne velkem projektu a v ramci moznosti jsem s nim celkem spokojen…

Přezdívka:

jsem rad, ze nejsem sam komu CRUD na domenovych tridach pripadaji zvrhle…

frantisek.troster

Doctrine 2 již nebude založena na návrhovém vzoru Active Record, ale naopak zavádí EntityManager, který zajišťuje persistenci objektů. ORM objekty budou tedy klasické objekty s anotacemi jako má např. Hibernate. Celé ORM se tím velice urychlí a především mnohonásobně zmenší paměťová náročnost, protože objekty zabírají méně paměti a garbage collector si s nimi snadno poradí (což u stávajících různě cyklicky provázaných objektů není možné).

Propel jsem používal několik let, ale vadila mi větší paměťová náročnost než u Doctrine a nemožnost efektivně optimalizovat komplexní dotazy (vždy se musel udělat krok stranou a použít čisté SQL a zbavit se výhod ORM). Při dalším projektu bych se být Vámi podíval i na Doctrine (resp. Doctrine 2, která bude během několika měsíců stabilní), možná Vás osloví.

smilelover

V tom pripade zni Doctrine 2 dost zajimave. Ja ale doufam, ze pri dalsim projektu uz nebudu nucen pouzivat PHP vubec ;)

Jinak co se tyka optimalizace SQL, tak to je fakt, ze tam jsem musel Propel dost priohybat. V podstate jsem si napsal vlastni mini-knihovnu pro cteni dotazu ulozenych v XML, ktera pak ty dotazy (a prip. dotazy na ne dale zavesene jako callbacky) spousti pres Propel a pres Propel je taky mapuje na objekty. Propel ale tu logiku mapovani schovava, takze jsem musel par jeho trid trochu „vyrabovat“… ;)

Petr Novotny

Mě osobně taky úplně nesedí CRUD na doménových třídách. Na druhou stranu, co se týče praxe tak je daleko pohodlnější volat např. $book->save(), než si sahat pro nějakou implementaci DataMapperu a předávat jí objekty na uložení. Tudíž mi připadá ideální mít v ORM možnost používat DataMapper zvlášť, ale zároveň mít volitelnou možnost poskytnout daným doménovým třídám API ActiveRecordu. Nevím ale jestli v současnosti nějaké ORM toto nabízí…

František Kučera

A to je takový problém použít EntityManager zavolat:

em.persist(kniha);

místo:

kniha.save();

?

V jednoduché aplikaci to vypadá jako ekvivalentní, ale pokud je aplikace distribuovaná nebo vícevrstvá, může (a zpravidla tomu tak je) objekt putovat do částí systému, které s databází nemají nic společného – a pak je nežádoucí, aby si s sebou objekt nesl tyhle metody a vazbu na databázi.

ToM

Ja si teda vzdycky myslel, ze ORM je mapovani objektu domenove modelu do relacni databaze. Tzn. veta

„Možnost zapouzdřit související funkce přímo do objektu reprezentujícího řádek tabulky“

je blbost. Ty objekty, co se mapuji, by prece nemely vedet o tom jak se ukladaji. To pak vznika zavislost, ktera neni uplne zadouci.

frantisek.troster

Ano, ale to jsou rozdílné přístupy mezi ActiveRecord návrhovým vzorem a nebo Repository návrhovým vzorem. U prvního přístupu je žádoucí a nezbytné, aby objekt věděl vše o své perzistenci v databázi. U druhého přístupu je situace opačná a přesně jak říkaté je zcela žádoucí, aby doménový model byl mapován pro něj neznámím správcem perzistence.

ToM

Souhlasim s tim, ze jsou to jine pristupy. Ale sypat ActiveRecord do stejne pytle jako vzor Repository, no nevim. Proste ActiveRecord je zrcadlo databaze v objektovem havu a s ORM nema nic spolecneho. Na urovni ActiveRecord je DataMapper, ten ovsem funguje opacne a mapuje domenovy model na relacni. A to je zaklad ORM.

none_

Chtěl jsem se zeptat, jestli tyto frameworky podporují lazy loading jako například hibernate v Java? Předpokládám, že ano, protože jestli ne, tak se stávají nepoužitelné…

Jednoduchý příklad: tabulky v DB Adresa – Autor – Clanek
Chci k článku vypsat adresu autora: $Clanek->autor->adresa

frantisek.troster

Ano, jak Doctrine tak i Propel ve výchozím nastavení použijí lazy loading. Nebo je možné vynutit načtení souvisejících záznamů, pomocí SQL joinu v jednom dotazu. Ve druhém článku (vyjde příští středu) je podrobněji rozepsán framework Doctrine a to i včetně možných variant načítání záznamu tabulky do proměnných.

none_

díky…

Srigi

Nedavno som zacal pisat projekt v Nette a nad modelovou vrstvou (M z MVP) som dlho rozmyslal. Kcel som pouzit Zend_DB ale toto bolo moc low-level, clovek si musi doprogramovat Data Mapper a to sa mi ako spravnemu lenivcovi nekcelo. Tak som sa prekonal a zvolil som Doctrine a musim konstatovat, ze lepsiu volbu som urobit nemohol.

Inak je zvlastne ako sa komunita okolo Nette drzi Db layeru Dibi.

Matej

> Inak je zvlastne ako sa komunita okolo Nette drzi Db layeru Dibi.

Dibi znam a libi se mi jeho jednoduchost a rychlost zapisu sql. To je zkratka navykove… i kdyz hur prenositelne. Ale, priznejme si, kdo dela v Dibi velke projekty, ze ano ;-)

Ped

Taky zkousim Nette+Doctrine 1 a zatim jsem docela spokojeny.

Doctrine 2 se mi moc nelibi, podle mne je to z pohledu OOP a abstrakce krok zpatky, i kdyz samozrejme pokud nekomu chybi ten vykon navic a nebo naopak mu vadi ze domenovy model toho vi o ulozeni v DB vse, tak je Doctrine2 asi dobra volba.

Ja osobne se snazim o TDD a po serii experimentu jsem dospel k zaveru ze:
– nechci pracovat primo s DB, chci mit moznost kdykoli zmenit DB lusknutim prstu. Z toho mi vyslo ze chci definovat objekty jako PHP class a nechat kod at vygeneruje DB strukturu + stara se o komunikaci s DB (Doctrine1 zatim splnuje na jednicku, prepnuti unit testu ze sqlite:memory na MySQL je otazkou prepsani jedneho radku s definici pripojeni, to same teoreticky i pro jine DB, ale to jsem zatim netestoval)
– nechci v ramci unit testu „mockovat“ skoro vsechny tridy, proto bych chtel poustet testy nad opravdovou DB, ale klasicke „skutecne“ DB vykonove naprosto nevyhovuji. Sqlite:memory mne trochu zklamala, ale je to jeste pouzitelne (V prumeru 10 testu zvladne za 0.3s proti 5s nad MySQL).
– porad hledam rozumny kompromis jak testovat samotny vystup webove aplikace, vypada to ve spojeni s Nette docela slibne, v podstate mi staci korektne vyvolat dany presenter a otestovat na vystupu co pripravil sablone, pripadne klicove data dohledat v samotnem html vystupu (ale tohle mi prijde uz relativne nezajimave, jsem spokojenej jiz kdyz vim ze sablona dostava spravne data, mozna u opravdu komplexnich stranek kde muze dojit k nejake zamene udaju v ramci sablony nebo nejake copy/paste chybe budu testovat i vystup)

Kdyby sem nechtel odstrelit definovani struktury DB, tak bych zustal u dibi.

Premyslim ze nekdy napisu nejaky „how to“ co se tyce kombinace TDD + Nette + Doctrine 1, jen se jeste na to necitim pripraven, chci ziskat trochu vic praxe s testovanim presenteru a celkove aplikace, ted jsem velmi spokojeny jenom s testovanim modelu. A jeste jsem nezkousel migrace mezi ruznymi verzemi modelu, kdyz uz budou v DB nejake zive data, Doctrine by to melo pomoct resit, ale musim si to jeste vyzkouset.
Pokud by takovy clanek nekoho zajimal, dejte mi to tady vedet, at vim ze to ma smysl. :)

Tom

ad „Pokud by takovy clanek nekoho zajimal, dejte mi to tady vedet, at vim ze to ma smysl. :)“

+1 v počtu zájemců o takový článek :)

frosty22

„chci mit moznost kdykoli zmenit DB lusknutim prstu“

Docela nechápu, proč se mezi stěžejní výhody ORM stále řadí možnost změn databází. Samozřejmě výhoda to je, ale převážně pouze u univerzálních systémů. Beru to tedy prakticky, ale u menších webových aplikací, tak stejně budete hosting hledat tak, aby splňoval požadavky aplikace, u větších aplikací, tak si necháte udělat server na míru a nebudete používat chvíli MySQL, chvíli MSSQL, apod.

Osobně jsem se v praxi setkal již z mnoha projekty, od malých po veliké, čili toto samozřejmě je hezká vlastnost na jednu stranu, na druhou stranu člověk pak nemůže využít ony DB plně, pokud to nepodporujou všechny drivery apod.

Nebo ve finále může chtít udělat kompilér, který by zvládat konverze PHP, Java, C++ :)

Není to výtka, jen podotýkám, že se na tuto vlastnost všude apeluje, ale praktické využití je minimální.

backup

kdyz to ctu, tk mam pocit, ze bych musel nejdriv vystudovat 2 vysoke skoly, nez bych napsal nejakou trivialni spravu adres. Uz jenom , abych vedel jestli je spravne mapovat to na ono nebo ono na to.

frantisek.troster

Dobrý den,

není to tak hrozné. Triviální správu adres napíšete bez znalosti vnitřních struktur. V okamžiku kdy budete potřebovat optimalizovat, což znamená, že se již nebude jednat o triviální správu adres, načtete další kus dokumentace týkající se této oblasti.

Jinak řečeno, dokud děláte na triviální aplikaci, nepotřebujete ORM, nepřinese Vám nic navíc. Když se ale aplikace rozroste, budete řešit, jestli psát nějaké vlastní řešení (zpočátku primitivní a postupně nabalované o stále více a více kódu) nebo použijete nějaké hotové a otestované. A pak ten čas, který byste strávil vývojem a testováním vlastního frameworku, věnujete načítání dokumentace. A podle mé zkušenosti to načtení dokumentace zabere desetinu a méně času než vývoj vlastního řešení.

analytik

Jeste pocas dne jsem tady videl vlakno „Propel vs Doctrine“ s par zajimavyma zkusenostema.

Rad bych dodal k clanku, ze aktualni verze Propelu, 1.5, ma query jazyk ne nepodobny Doctrine. Dulezite je ale zminit, ze Doctrine pouziva runtime introspection a je delany podle Hybernate, kdezto Propel si bere za vzor Apache Torque a modely kompiluje (generuje prazdne classy jednotlivych modelu + jejich base, Peer, Critera a Query classy) s pomoci Phing.

Benchmarky z blogu Propelu i Doctrine ukazuji, ze Propel je temer vzdy rychlejsi, teda aspon v porovnani se soucasnou stable Doctrine (1.x). Doctrine 2.0 alpha vsak ukazuje velke zlepseni vykonu.

V cem ma Doctrine 2.0 taky navrch je pro me podpora namespace, ktere v Propelu jsou zatim v nedohlednu (neobjevi se teda v nejblizsi verzi, 1.6).

Ale, vzhledem k benchmarkum a zkusenostem pritomnych uzivatelu bych se rad zeptal autora clanku co myslel vetou „Hlavní nevýhoda Propelu je v zastaralém jádru knihovny“ – je to skoro jedine, co o Propelu pise, na zaklade ceho usoudil, ze Propel je vhodny jenom na legacy projekty, coz se mi zda trochu mimo realitu.

analytik

Ups, omlouvam se, thread ‚Propel vs Doctrine‘ je na tretim dilu.

Citat o ‚zastaralem‘ jadru propelu je z druheho dilu.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.