Jak jsem hledal ORM pro Nellu
Když David Grudl na sklonku roku 2009 psal tento tweet . Zasmál jsem se mu a říkal jsem si kolik takových ORM vlastně vznikne. Pokud toto téma sledujete tak víte, že jich vzniklo celkem hodně. Když jsem začínal pracovat na Nelle tak jedním z požadavků na systém bylo jednoduchá rozšiřitelnost. No a to jde ruku v ruce s dobrým objektovým návrhem modelů celé aplikace. Proto jsem se začal ohlížet po nějakém tom ORM, které bych pro tyto účely v Nelle použil. To jsem neměl dělat, protože to byl běh na dlouhou trať s nejasným výsledkem.
Stanovení požadavků
Prvním problémem bylo, že jsem si musel utřídit jaké mam na takové ORM vlastně požadavky. Jelikož jsem do té doby žádné ORM aktivně nevyužíval, bylo to o to těžší. Sám jsem totiž v modelové části aplikace postupně procházel vývojem kdy jsem používal Table Data Gateway později Row Data Gateway a nyní jsem chtěl přejít na nějaké to „pořádné“ ORM vycházející z Active Record nebo Data Mapper . Tak a měl jsem první požadavek. Dalším bylo aby toto ORM vycházelo pokud možno z dibi . V Nette komunitě je totiž velice oblíbená (troufám si tvrdit že u 90% aplikací používaná) kombinace Nette Framework + dibi . Jelikož mě nic dalšího nenapadlo tak jsem měl tímto definovány všechny požadavky a mohl jsem začít hledat.
dibi ORM
S ohledem na požadavek dibi jakožto
základu jsem neměl moc na výběr. Existovala v zásadě dvě řešení. Na
první pohled sympatičtější dibi-activerecord,
které bohužel autor dále nevyvíjí
(zřejmě z důvodu že přešel na Ruby on
Rails). Původní verze Nelly na něm byla
dokonce postavena. A druhé Ormion od Honzy Marka nicméně toto řešení se mě
nelíbí kvůli ošklivým ini souborům, které používá. A tak
jsem začal pátrat za hranicemi dibi . A tu
se vyvalili stovky řešení. „Omrknul“ jsem jich asi 20–30 a
skoro všechno to byly hrozně nepřehledné knihovny. S nimiž by
byla práce spíše utrpením než radostí.
Ostatní
Mezi těchto 50 se vešly i 2 hodně známé knihovny Propel a Doctrine . Tyto knihovny
jsou hodně rozsáhlé a řeší snad vše, na co můžete narazit při
mapování databáze na PHP objekty. Nicméně mně na nich vadí dvě věci.
Tou první jsou opět podivné
yaml/xml soubory pro mapování, které my
jsou proti srsti. A tou druhou je že se jedná o poměrně hodně velké
knihovny. Nemám rád velké knihovny (obecně se dá říct,
že cokoli co má víc jak 1MB je pro mě velká knihovna). Obsahují
toho totiž tolik, že čtení jejich dokumentace a učení se jak je používat
je na strašně dlouhou dobu (To je také důvod proč nepoužívám Zend Framework). Já raději malé
knihovny, které toho umějí tak akorát ale jsou promyšlené a to co
dělají, dělají pořádně (třeba Nette
Framework). K čemu je mě obrovská knihovna se spoustou funkcí
když jich využiji sotva 20%?
Doctrine 2.0
Světlo na konci tunelu. Pokud jsem se v předchozím textu bavil o Doctrine měl jsem na mysli verzi 1.2 . Doctrine 2.0 když jsem si poprvé prohlížel dokumentaci musel jsem na své okolí působit jako malí klučina který právě pod stromečkem našel své první autíčko na dálkové ovládání. Zamiloval jsem se! Nicméně po delším a delším zkoumání mé nadšení opadalo. Důvodem bylo že Doctrine je knihovna která řeší snad všechny možné problémy. A to je taky kámen úrazu protože aby bylo možně některé tyto problémy řešit, musejí být některé na první pohled banální záležitosti řešeny složitě. A druhým výše zmíněným úskalím je že se opět jedná o „mamutí“ knihovnu.
No a jak to všechno dopadlo a jak jsem nakonec vybral? To se dovíte v dalším článku.
7 komentářů
Hrach
nový
Já si tipuju notorm :)
Martin Sadový
nový
AR od Romana – špatné a to dost, dělal jsem na něm projekt a už jej nechci vidět
Ormion – Zajímavá věc, když pominu generované ini soubory s úpravou, tak bych ho rád vyzkoušel v praxi
Doctrine 2. – Šílené, musím říct, že je to hrozně velká a šílená knihovna ale pozitivní věcí co jsem si odnesl jsou entity, pro mě nové řešení a líbí se mi
A tedy mě už napadla myšlenka „Vyladit Ormiona na Entity?“ zdá se mi to jako perfektní.
(Propel jsem nezkoušel..)
Josef
nový
Zdravím.
Jen bych se rád vyjádřil k některým tvým kritériím a argumentům (vlastně jen k jednomu .) ):
„K čemu je mě obrovská knihovna se spoustou funkcí když jich využiji sotva 20%?“
(Nereaguji pouze na citaci, ale celkově k velikosti knihovny atd.)
Proč nevyužívat spokojeně těch 20%? Problémem malých knihoven dle mého je to, že si člověk říká, jak jsou super, lehké, přesně jak jsi napsal a pak… to nestačí. A začne nad těma lehkýma knihovnama psát další své knihovny. Ovšem s tím, že dělá již udělané, tedy přesně to, co by nemusel dělat, kdyby místo programování přečetl dokumentaci větší knihovny a smířil se s tím, že z ní bude zatím používat akorát část.
Momentálně dělám s Propelem 1.5, má své mouchy, má své masařky, dokumentace je pro začátek výborná, později musí člověk zabrouzdat do dokumentace starších verzí (PropelPager je fajn věc, ale v dokumentaci o 1.5 se o něm člověk nedozví). XML mi vadí, velké vygenerované třídy taky (Doctrine 2 styl (JPA styl .) ) bych velmi uvítal, ale web bude nasazen asi na PHP 5.2.*, takže si s tímhle nechci přidělávat další starosti).
Co jsem tím předchozím odstavcem chtěl říct? Že kdybych si všechno psal sám, tak mi rupne v bedně vzhledem k deadlinu (hm, tohle bych neměl psát, ale měl bych makat). Kdybych použil menší knihovnu, tak musím dopisovat věci, které mi později budou chybět, místo toho, abych prostě zabrouzdal do dokumentace (a třeba to nenašel, ale to už je problém počátečního výběru .o) ). Aneb získal jsem jedním vrzem něco, co mi nyní okamžitě stačí – tzn. to, co jsem schopen se v krátké době naučit (snad výkonně) používat a s tím, že v budoucnu budu prostě objevovat věci, jak něco řešit lépe. .) Aneb místo programování vlastních nedokonalých fičur, budu refaktorovat kód a znalosti – a to i s rizikem, že najednou prozřu a na další projekt se budu stěhovat k jinému frameworku / ORM – znalosti a zkušenosti se neztratí. .)
Honza Marek
nový
Jo, taky se mi nelíbí ošklivé ini soubory. Koumám co s tím. Buď je zrušit a typy políček normálně cachovat + asociace řešit anotacema třeba. Nebo generovat rovnou celé základní třídy někam, ale s tim jsou komplikace podobné jako s ini souborama. Výhodou by bylo snažší přizpůsobení, které se teď řeší různými callbacky a filtry.
Josef
nový
Jen dodatek k předchozímu (nechtěl jsem dodávat, dokud jsem si nebyl jist, že příspěvek nesežral internet):
Samozřejmě jsem si vědom, že vybrat ORM k projektu, který není na jedno použití, ale defakto bude sloužit jako základ pro další projekty, je obtížnější. Ale tím spíš bych nehleděl na kritérium velikosti a zauvažoval, jestli knihovnu připojenou k CMS nepoužije i někdo další a jestli fičury dané knihovny nebudou potřeba v budoucnu, i když teď hned pro ně není užití, ať už z jakéhokoliv důvodu (probírání se dokumentací, ověřování v praxi atp.).
Každopádně hodně štěstí při dělání Nelly. .)
Patrik Votoček (Vrtak-CZ)
nový
[5] Josef přesně tak vybrat jakoukoli knihovnu kterou má používat OpenSource projekt není žádná sranda už jenom kvůli vhodné licenci.
Honza Marek
nový
Jo, zrušil jsem ini soubory u Ormionu. A ani to moc nebolelo. Asociace se teď zapisují přes anotace.