neděle 1. listopadu 2009

Do pranice: Vhodnost ORM

Dvakrát se mi v poslední době stalo, že jsem se snažil někoho přesvědčit o nevhodnosti použití Hibernate a obecně ORM nástrojů pro přístup do databáze. ORM přístup má svoje výhody, ale i věci, které činí jeho použití obtížné.

Faktory, které ovlivňují jestli je ORM vhodná volba.

  • Aplikace pracuje pouze s více typy databází. V takovém případě přináší ORM neocenitelné služby v oblasti přenositelnosti. Ta nemusí být dokonalá, ale určitě převáží nad práci vynaloženou nad portací vrstvy pro přístup k datům pro N dalších typů databáze.
  • Aplikace potřebuje číst a zapisovat košaté objektové struktury. Zde nám ORM neušetří práci na psaní dotazů, ale ušetří nám hromadu kódu, který bude potřeba na jejich zpracování. Mám na mysli především kód, který prochází ResultSet a staví objektový strom a naopak kód, který prochází objektový strom a staví PreparedStatement.
  • Aplikace si může dovolit upravit RDBMS schéma, aby vyhovovalo objektově-relačnímu mapování. Ačkoliv Hibernate nabízí doslova kouzla pro namapování čehokoliv na cokoliv je lepší upravit RDBMS schéma, tak aby vyhovovalo.

Jednou z charakteristik ORM frameworků je jejich snadná počáteční adopce. Tyto řešení fungují velice snadno pro vzorová schémata typu: potřebuji namapovat one-to-many vztah, potřebuji získat entitu na základě jejího identifikátoru. Řekl bych, že tato vlastnost a databázová přenositelnost je pozlátko, které hodně vývojářů zláká. Bohužel je zde i temná strana síly, se kterou zahrávati neradno je a počítati musí se s ní.

Osobně bych to vyjádřil takto, pokud nemáte v týmu někoho se zkušeností s ORM, čeká vás plno nemilých překvapení. To je dané komplexností ORM a vy pravděpodobně nemáte ani tucha co je pod kapotou. První vystřízlivění nastává ve chvíli kdy si zapnete výpis SQL dotazů následované LazyInitializationException a zakončeno magickými zápisy do databáze, které vám nedávají smysl.

To střízlivění a bolehlav je důsledkem komplexnosti, kterou ORM představuje. Takže kromě toho, že se učíte jazyk vlastního frameworku, musíte vstřebat a pochopit právě tuto komplexnost. Stejně jako máme návrhové vzory pro objektově orientovaný návrh nebo návrh enterprise systémů, tak máme i vzory pro to jak úspěšně používat ORM. A věřte mi, že máte problém pokud ty vzory neznáte.

Nerad bych, aby tenhle článek vyzněl tak, že ORM je špatné. To v žádném případě není. Jenom je dobré si uvědomit, že jako každé řešení se pro některé úkoly hodí více, pro některé méně a pro některé vůbec. Samozřejmě je na místě otázka co jiného když ne ORM. Docela dobrý kompromis mezi komplexním ORM a nízkoúrovňovým JDBC představuje framework iBatis (viz třeba Honza Novotný iBatis 3.0 preview – část první), kdy mapujete objektový graf na SQL dotazy namísto tabulek.

Budu nesmírně rád pokud mi zde pod článkem vyjádřite svůj názor o vašich zkušenostech s ORM.