V předchozím článku jsem řešil, zda o data žádat přímo repository, či zda žádat service. V tomto článku bych rád otevřel diskusi nad dalším „problémem“, který řeším.

Když jsem se rozhodoval , jakou knihovnu použít pro modelovou část Nelly, byla jednou z možností Doctrine ORM. Původně jsem si Doctrine ORM 2 nevybral a začal jsem psát vlastní ORM, postavené nad dibi. Po přibližně měsíční práci jsem dospěl do fáze, kdy to nějak fungovalo, ale čekala mě hromada další práce, jako například optimalizace, celkový refaktoring a hlavně otestování v praxi. V tu dobu jsem své předchozí stanovisko nepoužít Doctrine znovu přehodnotil a začal ji používat.

V těchto dnech tomu bude rok, co používám Doctrine. Je to výborná knihovna a autoři na ní odvedli velký kus práce. Nicméně ani Doctrine není kompletní řešení modelové vrstvy aplikace. Schází jí totiž poslední „kostička do skládačky“. Tou je modelová Service vrstva.

Jak řešíte ukládání dat s ověřením unikátnosti záznamu?

V předešlém článku jsem sepsal své strasti při hledání vhodného ORM pro Nellu . Popsal jsem v něm hrubé požadavky, které by měl kandidát splňovat. Popsal jsem, proč jsem nezvolil Ormion, dibi-ActiveRecord, Propel, Doctrine 1.2 a ani Doctrine 2.0.

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.