pondělí 11. června 2007

Populární anti-patterny

Nedávno jsem na jednom školení vedl polemiku o návrhovém vzoru Data Transfer Objects. Tenhlo vzor de facto odděluje závislosti mezi jednotlivými vrstvami aplikací. Klasický příklad je view vrstva a vrstva business logiky aplikace. Díky DTO není vazba mezi těmito vrstvami tak silná. Dalším pěkným příkladem je View Helper, který slouží jako prostředník mezi světy komunikačního protokolu a business logiky.

Proč zrovna mluvím o těchto vzorech? Protože na ně vývojáři rádi zapomínají. Položte si otázku, v kolika svých aplikacích jste použili DTO namísto propagování domain objektů, které zároveň sloužily jako persistentní entity. Hádám, že jich moc nebylo, tedy spíše žádná. To znamená, že architektura Vaší aplikace není sice čístá, nicméně dostatečně vyhovující proto, aby plnila to co má.

Základní myšlenkou Seamu je to, že umožňuje EJB beany vystavovat jako managed beany pro JSF. Dokonce se tenhle přístup stal základem pro JSR 299: Web Beans. Jinými slovy business logika aplikace je view helper a tím pádem odpadá nutnost psaní tohoto prostředníka. Jak lákavé, sice nám tím odpadne nutnost dalšího kódu, ale za jakou cenu?

Architektura naší aplikace opět nebude čistá a v tomto případě to bude mít dokonce implikace, protože business logiku si toho bude muset být vědomá - anotace, programový model. Na druhou stranu dá se s tím žít.

Dlouhou dobu jsem měl pocit, že návrhové vzory, teď myslím ty enterprise, jsou prostě v Jave zakořeněny, a každý kdo chce používat Javu to bere na vědomí. Na oplátku dostane solidní šanci, že jeho aplikace nebude jednorázovým slepencem bez možnosti dalšího rozšíření. V poslední době ovšem zdá se mi, že Java tuhle architektonickou čistotu opouští.

V první řadě za to může zřejmě nástup frameworků jako Ruby On Rails, protože to lákadlo udělat něco tak jednoduše je prostě neodolatelné. Samozřejmě zmíněná jednoduchost má svou daň v tom, že architektura aplikace není zdravá. Druhý důvod je možná ten, že většina vývojářů nepotřebuje ten přínos, které enterprise vzory přinášejí. Jinými slovy například důsledné oddělení view vrstvy a business logiky není pro ně přínosem.

To ve mě vyvolává otázku jestli se Java opravdu zaměří na oblast Rapid Application Developmentu. Tam je nebezpečí v tom, že jde především o to, aby to rychle a nějak fungovalo, což sebou nese právě rizika v ne úplně čísté architektuře. To je v podstatě model, který má PHP, který funguje dobře z krátkodobého hlediska nicméně z hlediska dlouhodobého se ukázal jako nefunkční.