Budu se zabývat reálným vývojem standardní desktopové aplikace (informačního systému), postavené na technologiích Microsoft: C#, WinForm, .Net Framework a MS SQL.
Vývoj každé DBA s sebou nese obvykle vysoké nároky na lidské zdroje, znalosti a časové náklady, které nebývá snadné současně naplnit. O míře jejich naplnění pak vypovídá kvalita hotového produktu. Podcenění některého z faktorů se odráží na konečném výsledku. Kritickým místem rozhodování je příprava zahájení prací, neboť v tomto okamžiku musí být jasné, kam směřujeme, jak to provedeme, co k tomu použijeme a co od výsledku očekáváme. Právě definice základních parametrů na počátku vývoje určuje, jaké další podpůrné nástroje třetích stran (frameworky) budeme či nebudeme moci použít.
Frameworků dnes existuje celá řada. Vhodnost jejich použití určují jak naše vstupní parametry zadání, tak i limity jejich možností. Tzn., že ne každý framework bude vyhovovat našemu zadání a bude pro naše záměry vhodný. Vybíráte-li si příslušný framework, je lepší nejprve začít s definicí vlastních pořadavků a následně použít takový nástroj, který bude vašim požadavkům v maximální míře vyhovovat. Jít opačnou cestou, tedy vybrat si framework, a následně po něm chtít splnit definované požadavky, nebývá nejlepším řešením. To vede ke kompromisům jak na straně vašeho zadání, tak na straně možností vybraného farameworku. Obvykle se pak vydáte třetí, náhradní, cestou.
Jako zcela zásadní parametry zadání pro vývoj DBA bych viděl následující body. Jejich rozšíření a priority si čtenář může upravit dle svého.
1. Zaměnitelnost jednoho typu RDB za jiný typ RDB
Na úvod jsem uvedl, že jako zdrojová RDB bude použit MS SQL. Na něčem začít musíme. Myslet na zaměnitelnost je velmi důležité z mnoha hledisek. Naše finání aplikace může být tak dobrá (bude tak dobrá), že o ni projeví zájem i klienti, kteří nedisponují licencemi na MS SQL, ale platí licence na jiné RDB systémy, na kterých to budou chtít provozovat. A další licence již platit nechtějí. Pokud na zaměnitelnost nemyslíme, pak svou práci od počátku degradujeme. Upravit již jednou odladěnou aplikaci na jiný RDB systém může být tak náročné, že budeme, de facto, paralelně vyvíjet zcela novou DBA. Lepší je přepsat pouze strukturu a procedury do nové RDB.
Na druhou stranu nás zaměnitelnost nutí psát „čistý kód“ bez zaplevelení celé řady commandů, connections, transactions a pod. Pokud se programátor obrací v kódu přímo na RDB, jak chceme uhlídat správné použití transakcí, otevírání a zavírání spojení, commandů, ošetření vyjímek a pod.? To je téměř neřešitelný problém a také příčina řady chyb. A implementovat dotazy, které jsou součástí kódu, je dalším kritickým místem. Zvláště jejich hledání, ladění, úpravy, následné kompilace a pod.
Výhodou nastavení počáteční podmínky zaměnitelnosti RDB je skutečnost, která nenutí programátory produkovat více či méně zdařilé RDB dotazy. Tím může být pověřen právě specialista na konkrétní RDB. Chybovost kódu se výrazně sníží, práce se standardizuje a zrychlí.
Podmínkou je možnost změnit původní RDB za jinou RDB a to bez nutnosti zásahu do stávajícího a odladěného kódu naší DBA.
2. Napojení DBA na RDB lokálně, VPN nebo WebServices
I přes to, že vyvíjíme standardní desktopovou aplikaci, nesmíme být odkázáni na RDB uloženou na lokálním počítači či provozovanou v rámci podnikové sítě (VPN). Desktopová aplikace musí umět pracovat s daty i přes webové služby. Je důležité umožnit uživatelům pracovat s aplikací nejen v kanceláři, ale i na služební cestě, z domu, z výjezdního zasedání a pod. Chcete-li, dát jim plnou mobilitu.
Jak se DBA bude napojovat na zdroj dat, je plně v souladu s bodem 2.
3. Rekonstrukce záznamů
Jedná se o standardní situaci. Uživatel změní hodnotu políčka, ať úmyslně či neúmyslně, a změnu uloží. Po pár minutách zjistí, že to nebylo správně a rád by se vrátil k hodnotě původní. Tu ale již zapomněl. Co s tím? Jak taková data zrekonstruovat do původní podoby? I to musíme mít na paměti.
4. Historie změn hodnot záznamů a jejich řízení
Co mám na mysli pod pojmem historie změny záznamu. My od DBA v podstatě chceme, aby v RDB držela popis reálného světa. Stručně řečeno, jednotlivé reálné objekty převedeme (snažíme se převést) na Db tabulky, kde jejich sloupce definují charakteristiky reálných objektů (výška, váha, barva, cena, …).
Jak se v reálném světě mění charakteristiky objektů v časové ose, nastává potřeba zaznamenávat tyto změny i v RDB. Příkladem může být, dejme tomu, zaměstnanec – žena. Nastoupila a v systému ji evidujeme pod řádkem 145 jako „Julii Novákovou“. Za nějakou dobu se vdá a její jméno se na řádku 145 změní na „Julie Malá“. Co se ale v RDB stane? Zde navazujeme na předchozí bod (rekonstrukce). Tím, že jsme příjmení zaměstnankyně změnili na příjmení nové, ztrácíme původní hodnoty! A to je špatně! Dnes se ale jedná o standardní situaci u většiny DBA.
Otázka zní proč? Představte si současné DBA. Spustili jste ji včera a dostáváte aktuální údaje ke včerejšímu dni (a hodině). Spustíte ji dnes a opět dostáváte aktuální údaj, ale k dnešnímu dni (a hodině), Uděláte-li to zítra, bude situace obdobná. To ale znamená, že se mohu „přepnout“ kamkoliv zpět, podívat se do minulosti, a vidět tak údaje, které byly v RDB aktuální právě ke zvolenému datumu! Není to zajímavé? Kdybych věděl, kdy se paní „Prášková“ vdala a nastavil datum v systému před její svatbou, dostal bych seznam aktuálních zaměstnanců k danému dni s jejich původními hodnotami! Samozřejmě, změněný záznam musí být označen, aby bylo na první pohled jasné, že byl změněn.
Tedy historie změn záznamů znamená možnost, jak zobrazit údaje z RDB k jakémukoliv datumu v minulosti a získat tak údaje v takovém stavu (obraz databáze), v jakém se tyto údaje v daný čas nacházely. A to je velmi důležité. Samozřejmě, že pohled do minulosti má své hranice.
5. Další definované požadavky
Snažil sem se poukázat na několik, z našeho pohledu významných, vstupních požadavků. Je na čtenáři, aby si zde doplnil požadavky vlastní, neboť cílem článku není úplný a konečný výčet, ale spíše naznačit myšlenkové pochody.
6. Vyhodnocení
Na projektu jsme se chtěli vyhnout klasickým ORM frameworkům. Jedním z mnoha důvodů byl i požadavek na „čistý kód“. Kód bez různých implementací dotazů a jejich dynamické konstrukce. Záměrem bylo přesunout práci s daty právě na RDB, které k tomu byly postaveny a dosáhnout i rychlejší odezvy.
To vše vedlo k tomu, že jsme zvolili Digital Data Cube Framework (DDCF). První volba padla proto, že beze zbytku splňoval naše podmínky uvedené v bodech 1 a 2. Ty byly pro nás stěžejní. Je nutno podotknout, že DDCF není ORM, ale je postaven na zcela jiném principu.
DDCF má ale implementovánu celou řadu dalších věcí. Umí pracovat s historií změn záznamů (s níž jsme koketovali), včetně jejich schvalování. Tento mechanismus jsme nemuseli vůbec implementovat. Důležité je, že umíme zrekonstruovat data do původní podoby před jejich nežádoucí změnou. A to velmi rychle.
Umí řídit záznamy v RDB, které jsou uloženy v různých stavech. Můžeme si tak zobrazit např. všechny editované záznamy, všechny schvalované záznamy, schválené záznamy a pod.
DDCF řeší i problematiku DELETE. Je jednoduché fyzicky odstranit záznam z Db. Co se ale stane v případě zapnutí CASCADE? To je problém. DDCF umí nepotřebné záznamy tzv. vyřadit. Pak se uživateli nezobrazují, ale chovají se, jako by v Db nebyly. Samozřejmostí je i jejich opětovné zobrazení či obnovení do původního stavu.
7. Závěr
Záměrem bylo poukázat na to, že stěžejním krokem vývoje DBA je příprava prací konaná s rozmyslem. A dále, že vhodně zvoleným nástrojem můžeme dosáhnout zajímavých možností. Nevhodně zvoleným pak pravého opaku. ORM frameworky nejsou samospasitelné, stejně tak i jiné nástroje, zde např. DDCF. Všechny mají a budou mít určitá omezení.
Pokud si některý z nástrojů zvolíme, měli bychom jeho potenciál využít na maximum. Přesto frameworky nesejmou břímě práce a zodpovědnosti jak z beder analytiků tak i z beder programátorů. Jejich práci mohou ale významně usnadnit a ovlivnit výsledek. Stále tak nejslabším článkem zůstává člověk.
ČLÁNKY DO MAILU