Doctrine vs. NotORM vs. zbytek světa
Jakub Vrána na dnešním Barcampu ve své přednášce srovnával Doctrine 2 ORM se svou knihovnou NotORM. V jednoduchosti kódu, počtu řádků a vykonaných dotazů nutných pro vypsání článků a přiřazených tagů z databáze zvítězilo nepřekvapivě NotORM, což z něj u naivních programátorů hned dělá kandidáta na modelovou část webové aplikace. Z čehož mi přebíhá mráz po zádech.
Hlavní motivací pro používání Doctrine je konzistentní reprezentace dat v aplikaci a práce s nimi. A tu mi zařídí objekty. Nikoli obálky nad funkce (třida se samými statickými metodami), ani obálky nad data (třída s public proměnnými či obecným ukládacím mechanismem jako DibiRow), ale skutečné objekty reprezentující nějaký smysluplný celek s nenarušitelnou konzistencí a metodami, které mi umožní práci s nimi.
Pokud to vezmu z toho konce, že chci do databáze uložit nějaké řádky a pak je zase vybrat, pak mám s Doctrine skutečně o mnoho víc psaní, které nedává smysl. Ale pokud si primárně stanovím, že chci v aplikaci pohodlně pracovat s konzistentními objekty, jak se to standardně dělá třeba v Javě (a PHPčkařům to stále neleze pod kůži), pro ukládání do databáze pomocí Doctrine už musím udělat jen minimum - napsat ke třídě a jejím proměnným pár anotací.
Jakou máme motivaci pro tento způsob psaní aplikace a odstoupení od jednoduchých databázových vrstev, jako je právě NotORM nebo dibi? Ve chvíli, kdy velikost aplikace překročí určitou mez, je model s de facto statickými metodami, ve kterém se míchá přístup do databáze, zápis do souborů a posílání mailů, dlouhodobě neudržitelný chaos. Na řadu pak přichází dnes již legendární pětivrstvý model, jehož nejbližší implementací v PHP je právě Doctrine 2.
Tato architektura umožňuje snadnou testovatelnost a tudíž i spolehlivost, flexibilitu (API modelu a tudíž ani prezentační vrstva se při překopání databáze nemusí měnit), je dlouhodobě udržitelná a když přijde řeč na vícejazyčnost a verzování, lze to udělat čistě a bez vytrhání všech vlasů. V této oblasti se NotORM, ani klasické Nette modely, jak byly dlouhou dobu komunitou upřednostňovány, skutečně nechytají.
Samozřejmě to není jediný správný způsob, jak k problému přistoupit. Některé firmy/projekty volí přístup mít všechnu logiku v databázi. PHP aplikace je pak stavěná pouze do role jednoduché prezentační vrstvy a všechny operace se provádějí pomocí databázových procedur. Proč ne.
V Doctrine je určitě prostor pro optimalizaci pokládaných dotazů a umím si představit, že by k tomu použila NotORM. Ale mít tuto knihovnu jako jedinou vrstvu modelu u rozsáhlejších aplikací vyvíjenými více lidmi moc dobře nejde.