Scream

Na začátek je potřeba definovat si, co považuji já osobně za framework.

Z definice, kterou nalezneme na Wikipedii vyplývá, že framework může být i pouhá sada doporučení používaných při vývoji. Já osobně za framework považuji spíše nějakou knihovnu nebo sadu knihoven poskytující API. K ní teprve přísluší sada doporučení popsaná v dokumentaci knihovny. CSLA této definici vyhovuje, avšak nevyhovuje mému základnímu požadavku na jakoukoliv knihovnu – měla by být co možná nejméně invazivní.

CSLA framework byl vytvořen pro platformu .NET a jeho tvůrcem je Rockford Lhotka. Autor pracuje pro společnost Microsoft a je zároveň autorem knihy Business Objects, která pojednává o samotném návrhu CSLA frameworku a způsobu jeho použití. Většinu informací budu čerpat právě z této knihy vydané v nakladatelství Apress. Konkrétně se jedná o druhé vydání.

Návrh frameworku vychází z požadavků na jeho funkce. Je určen pro implementaci business vrstvy a má umožňovat tvorbu distribuovaných aplikací. Datové objekty využívající framework mají disponovat schopnostmi data bindingu pro Windows Forms a Web Forms a tzv. N-level undo – tedy jakousi schopností pamatovat si historii svých stavů, kdy je možné vrátit objekt do kteréhokoliv ze zapamatovaných stavů. Další možností je zachycení vztahu typu nadřízený, podřízený objekt a podpora pro validaci a autorizaci datových objektů.

Kniha a framework samotný je však z mého pohledu plný sporných nebo zastaralých řešení. Právě to mě přinutilo zvolit podobný nadpis článku. Někdo by se mohl ptát, proč psát článek o něčem, co nepovažuji za vhodné k použití. Důvod je však naprosto jednoduchý. V dnešní době hemžící se samopochvalnými informacemi nebo recenzemi, které si někdo v podstatě zaplatí, by se měly objevovat i informace o negativních zkušenostech, které mohou ušetřit případný neúspěch při pokusu o reálné využití daného projektu.

Je čas ponořit se do útrob frameworku.
Úvodní část zmiňované knihy popisuje rozdělení aplikace na logické vrstvy. Logických vrstev je podle knihy 5: Prezentační, vrstva pro UI, vrstva business logiky, vrstva pro přístup k datům a data. Toto rozdělení je poměrně dobře známé, uvedu snad jen, že prezentační vrstvou se myslí pouze zobrazení informace a vrstvou pro UI v podstatě metody pro přípravu dat, která mají být zobrazena prezentační vrstvou a navigace. U webové aplikace je toto oddělení poměrně dobře patrné, u GUI aplikací se vetšinou spojuje prezentační vrstva a vrstva UI.

Kniha se zmiňuje o důležitosti podobného dělení. Důvody jsou poměrně jasné – modularita, znovupoužitelnost, škálovatelnost a podobně. Avšak v dalších částech knihy věnovaných přímo návrhu frameworku a způsobu jeho využití nám je najednou předkládáno doporučení, které spojuje 3 vrstvy do jedné – jsou to vrstvy pro business logiku, přístup k datům a vlastní data. Takto vznikají tzv. Business objekty.

Jaké jsou důvody pro tuto degeneraci návrhu aplikace? Jedním z důvodů je údajně zapouzdření objektu. Autor zastává názor, že logika potřebná k uložení objektu do databáze porušuje požadavek na zapouzdření objektu. Musíme přiznat, že pokud by měla být data objektu určena například pouze pro čtení, potom při načítání objektu z databáze potřebujeme způsob jak vložit data do objektu, tedy nějaké metody pro nastavení dat. Tyto metody může ovšem použít každý, čímž objekt přestává být určen pouze pro čtení. Podobné požadavky můžeme mít i pro samotný konstruktor objektu. Ovšem daný scénář by se dal vyřešit třeba třídami mapujícími atributy na data získaná z nějakého datového zdroje umístěnými ve stejném balíčku a nastavením příslušných modifikátorů u metod nastavujících data. Navíc v době ORM frameworků, které pracují na základě reflexe, se zdá být tento důvod zcela neopodstatněný. Další problémy autor spatřuje v business logice, která by měla podporovat distribuované zpracování – tedy část z ní může běžet na lokálním stroji a část na vzdáleném aplikačním serveru přitom programátora by nemělo zajímat, kde je daná část zpracovávána. Tento scénář splňují podle autora právě Business objekty. Business objekty jsou také označovány jako mobilní – to znamená, že mohou být předávány z klienta na vzdálený server a naopak.

Jaké jsou důsledky použití Business objektů? Následující kostra třídy ukazuje základní tvar každého Business objektu
class Zamestnanec : BusinessBase<Zamestnanec>
{
// atributy

// staticke metody pro vytvoreni nove instance objektu, pro nacteni objektu z databaze apod.

// staticke metody pro ulozeni objektu (at noveho nebo v databazi jiz existujiciho)

// metoda pro nastaveni pristupovych prav k objektu vyuzivana bazovou tridou (template method)

// medoda pro nastaveni validacnich pravidel objektu vyuzivana bazovou tridou(template method)

// metody pro insert, update a delete z databaze obsahujici primo volani sql dotazu vyuzivane tzv. Data portalem

// metody pro business logiku
}

První věc, která by nás měla mrzet je, že Business objekt vždy dědí od nějaké bázové třídy frameworku. Můžete nad tím klidně mávnout rukou, avšak v některých situacích je velmi důležité mít v možnosti dědění volnou ruku. Důvody pro nutnost dědění jsou zřejmě tyto – umožnění data bindingu a vzdálené provádění některých metod business objektu.

V příští části se podíváme na třídu business objektu zblízka. Pokusím se v ní obhájit své tvrzení o zastaralých a sporných řešeních.