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”((Object-relational mapping)) 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”((Object-relational mapping)), 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”((Object-relational mapping)) vlastně požadavky. Jelikož jsem do té doby žádné “ORM”((Object-relational mapping)) 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”((Object-relational mapping)) vycházející z Active Record nebo Data Mapper . Tak a měl jsem první požadavek. Dalším bylo aby toto “ORM”((Object-relational mapping)) 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](http://github.com/romansklenar/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.