Jelikož se v posledních dnech na českém internetu rozjela debata (zde, zde a nebo třeba zde), zda je lepší Doctrine 2, nebo NotORM Jakuba Vrány, rozhodl jsem se udělat menší průzkum. Měl mi ukázat ukázat první kroky, které podnikáme, programujeme-li novou webovou aplikaci, neb si myslím, že odpověď na výše zmíněnou otázkou s tím velice úzce souvisí. Otázka zněla: “Když začnu programovat novou webovou aplikaci, udělám napřed…” a měla tři možnosti:
- Udělám databázové schéma
- Začnu programovat třídy entit
- Něco jiného
Důležité pro mne byly první dvě možnosti. Třetí jsem zařadil pouze ze zvědavosti a také kvůli tomu, aby někdo neměl pocit, že ho do něčeho tlačím.
Proč právě tyto možnosti?
Inu, to máte tak. Ještě před pár měsíci, když mi někdo začal vykládat problém, který by aplikace měla řešit, mi jako první věc v hlavě šrotovalo: “Jo, tak to bude tahle tabulka, tohle rozložíme do vazby m:n, tohle, tohle bude odkazovat samo na sebe…”, a tak dále a tak dále. Nicméně, pak přišla změna. Nevím, kdy nebo kde to přesně začalo, ale nejintenzivnější to bylo na jaře 2010, kdy jsme v Mediu hodně debatovali o tom, jak řešit modelovou část v MVC. V tu dobu jsem se dozvěděl, že existuje nějaké DDD, že existují entity a že se celý model dá velice hezky vrstvit (tedy, to jsem už nějakou dobu věděl, ale tápal jsem mnohem více než tápu nyní :-)).
Když nad tím nyní přemýšlím, byl to přesně ten okamžik, kdy se ve mně zlomil názor, že přemýšlet jako první o rozložení modelu do databázových relací, je naivní, protože to není v danou chvíli vůbec podstatné. Mnohem důležitější je přemýšlet jak vyrobit kód, který na základě zpodobnění věcí z reálného světa začne řešit problémy uživatele. A to, jestli budeme ukládat data do nějaké (relační) databáze, to mi může být zatím jedno.
Jaké jsou výsledky
Po několika hodinách jsou výsledky následující:
- 53% – nejdříve dělá databázové schéma
- 31% – začne psát třídy entit
- 16% – dělá něco jiného
Hlasovalo celkem 62 lidí (díky všem hlasujícím). Myslím, že pro základní zorientování nám to postačí. Nepředpokládám, že by se procenta ještě nějak zásadně hýbala. Pokud vás zajímá konkrétní podoba třetích odpovědí, podívejte se na výsledky, stejně tak tam naleznete nejaktuálnější výsledky.
Jak si výsledky interpretuji já a jak to souvisí s naší ORM otázkou
Jak jsem již napsal, myslím, že souvisí úzce. Z mého pohledu se totiž Doctrine 2 výborně hodí pro situaci, kdy dostanu problém a chci ho začít řešit tak, že po úvodním rozmyšlení začnu psát přes testy prototypové třídy. Na způsob persistování stavů objektů myslet nemusím, protože to mi Doctrine nějak zajistí. Ti odvážnější se dokonce mohou spolehnout na automatické generování SQL přímo z entit :-). Teď se chci soustředit na to, jak vyřešit doménu problému.
První možnost mi naopak přijde jako překonaná. Soustředění se na tvorbu databáze je v tuto chvíli plýtvání energií. Důležité je co nejdříve vyřešit problémy, se kterými za námi zadavatel přišel, ne je rozkládat do nějakých tabulek.
Nechci, aby to vypadalo, že prohlašuji, že NotORM nabádá stavět se k tvorbě aplikací překonaným způsobem. Na to NotORM neznám dostatečně dobře (ostatně otázka neznalosti jednoho či druhého je zde asi ten nejzásadnější problém, dokud nepřijde někdo nestranný a dostatečně fundovaný, budeme se přít donekonečna) a věřím, že Jakub bude mít v každém rukávu hromadu důkazům že to tak není. Z ukázek na webu NotORM mi ale přišlo, že nevede programátory k tomu, aby začali psát nějaké entity a nestarali se o podobu dat v databázi. Přišlo mi, že se spíš hodí na řešení menších problémů pomocí tzv. transakčních skriptů. Transakční skripty jsou efektivní na malé problémy, nebo lépe řečeno na problémy u menších aplikací či v menším (cca 1 – 2 soudím) týmu programátorů. Ve svých prasárnách se každý přeci vyzná :-)
Na závěr zbývá uvést několik věcí na pravou míru
Napsal jsem, že mi přijde správné, že se člověk nemusí starat o podobu uložení dat v databázi. Pokud mne někdo trochu znáte, tak možná víte, že občas žehrám na to, že většina webových programátorů nerozumí databázím (respektive SQL) a že se v tomhle ohledu musí ještě hodně co učit (včetně mne). To, že mi ORM dává možnost soustředit se napřed na doménové problémy mi ale nepřijde jako rozpor. Na optimalizaci dat uložených v databázi bude ještě spousta času. Stejně většinu problémů poznáte až za ostrého běhu a bude-li aplikace úspěšná, začnou problémy přicházet stejně rychle jako bude růst počet aktivních uživatelů.
Stejně tak často říkám, že ORM jsou neefektivní co do alokace systémových prostředků. Ano, opravdu jsou. Zde z mého pohledu ale také nejsem v rozporu sám se sebou. Jsou typy aplikací, u kterých vím, že mi ORM přinese více problémů než-li užitku, takže na něj rovnou zapomenu a začnu entity stavět nad nějakou jednodušší databázovou vrstvou. O těch zde ale nepíši, vetšinou je jich méně než těch malých a středně velkých, na které ORM stačí.
A v neposlední řadě věřím v to, že je Jakubovo NotORM po výkonnostní stránce někde jinde, než je Doctrine 2.
I přesto ale můj palec nahoru míří k Doctrine 2, protože je to ona, kdo mi umožní rychle psát v duchu DDD jednotlivé vrstvy modelu.


