I když absence jakékoli aktualizace na blogu minulý týden by nasvědčovala tomu, že si dovolené již užívám, nebylo tomu tak a k psaní spotů jsem se nedostal, protože jsem finišoval neodkladné (tedy alespoň podle zákazníků) projekty v práci.

Takže do 22.9. se zde pravděpodobně žádný zápisek neobjeví, protože mě i manželku Yuhůovy (snad se Yuhůů takhle skloňuje, tady můj jazykový cit opravdu selhává) skvělé stránky o Krétě zlákaly k její návštěvě. Jedinou neznámou pro nás je, jak bude vypadat taková dovolená s patnáctiměsíčním extrémně aktivním dítětem.

O nic ale nepřijdete, po návratu budu hned pokračovat v seriálu o frameworku pro business objekty a také se podělím o některé poznatky ze zkoumání .Net Frameworku 2.0 (webové služby, .Net Remoting, vývoj pro PDA). A brzy poskytnu i další podrobné informace o chystaných a již dříve oznámených stránkách specializovaných na původní články o analýze, designu a vývoji aplikací.

Dokážete napsat jeden řádek kódu, kterým přířadíte statickému členu BField řetězec  "Milujeme porušování zapouzdření"? ;)

        sealed class A
        {
            private sealed class B
            {                    
                            private static string BField;
             
                        }
                    }

Na konci spotu, v němž byla vytvořena třída DataCacheHelper, jsem slíbil, že ukážu, jak si vynutit použití objektu DataCacheHelper všemi třídami v business vrstvě. K tomu nám poslouží vzor Layer SuperType, jehož definice se dá parafrázovat takto: zaveďme společného předka pro všechny třídy jedné vrstvy aplikace, v němž zapoudříme společný kód a sdílené chování.

Nyní si popíšeme rozhraní a implementaci vzorového předka pro business objekty. Zobrazit kód. (C#)

Abstraktní třída BusinessObjectBase obsahuje dva konstruktory. Bezparameterický konstruktor je potomky vyvoláván při zakládání nové instance bez obrazu v databázi ("bez platného - perzistentního id). V tomto konstruktoru nastavíme, že objekt není změněn vůči datům v databázi (m_isDirty = false), přidělíme mu dočasné id uložené v konstantě NO_ID a voláním privátních metod setNew a setLoaded označíme objekt jako "nový - bez obrazu v databázi" a současně "není třeba nahrávat data z databáze". U každého nového objektu se také předpokládá, že jde o aktivní objekt - tedy o objekt, který nemá příznak smazán (Discarded) ani neaktivní (InActive) - viz enumerace ObjectState na konci výpisu.

Druhý konstruktor, který přijímá argument id, používají odvozené objekty, jestliže již byly dříve uloženy do databáze. Opět nastavíme příznak, že objekt není změněn vůči datům v databázi (m_isDirty), dále nastavíme proměnnou m_isLoaded na false, což je příznak, který signalizuje, že data objektu ještě nebyl nahrána z databáze, a uložíme si id objektu.

Veřejná vlastnost IsDirty vrátí true, jestliže byl objekt změněn vůči datům v databázi, vlastnost IsNew vrátí true, jestliže se jedná o nový objekt bez perzistence - čeká na "Insert".

Vlastnost IsDeleted má hodnotu true, když již byla data objektu v databázi smazána příkazem Delete (objekt jen "dožívá" v business vrstvě) nebo když u objektů, jejichž data se například kvůli zachování referenční integrity fyzicky nemažou, byl do databáze zapsán stav Discarded.

Vlastnost Id vrací unikátní identifikátor objektu, jestliže byl objekt uložen do databáze, jinak vrací konstantu NO_VALUE.

Vlastnost ObjectState vrací stav objektu s využitím hodnot enumerace ObjectState (aktivní objekt, dočasně neaktivní objekt, smazaný objekt).

Metoda Load je pro nás zajímavá hlavně tím, že si vynutíme použití třídy DataCacheHelper. Jedná se metodu se šablonou (vzor Template method), která nejprve zkontroluje, jestli jde o objekt, který již byl nahrán a/nebo který byl již smazán - pokud je jedna z těchto podmínek pravdivá, metoda Load ihned ukončí svoji činnost. Když jsou všechny předběžné podmínky pro vyvolání metody Load splněny, metoda se pokusí vyzvednout dříve uložený řádek s daty pro svou instanci z třídy DataCacheHelper. Jestliže řádek existuje, pak je vyvolána varianta metody DoInternaLoad přijímající odkaz na řádek, jinak je vyvolána metoda DoInternalLoad, která musí řádek z databáze teprve získat. Metody DoInternalLoad jsou chráněné a virtuální a za jejich implementaci odpovídají odvozené třídy - třída BusinessObjectBase dbá na dodržení základní kostry algoritmu, ale implementaci jednotlivých kroků aloritmu ponechává (musí ponechat) na podtřídách, což je hlavní idea vzoru Template Method. Po úspěšném nahrání objektu je volána metoda setLoaded, která označí objekt jako nahraný (IsLoaded bude nyní vracet true).

Poznámka: V metodě Load se zatím předpokládá, že data objektu potřebujeme nahrát pouze jednou a metoda tedy neumožňuje aktualizaci dat objektu z databáze po prvním nahrání. Jak aktualizaci dat z databáze odvozeným třídám umožníme, si ukážeme v dalším pokračování.

Metoda Save neumožní uložení objektu, jestliže jde o nenahraný objekt ("není co ukládat, data nemohla být změněna"), jestliže jde o vymazaný objekt, nebo pokud objekt nebyl změněn a současně nejde o nový objekt. Metoda tedy již na úrovni předka ošetří, že nebudou zbytečně ukládány objekty, jejichž data byla nahrána, ale uživatel je nijak nezměnil. Metoda pouze volá chráněnou virtuální metodu DoInternalSave a jak asi ti chytřejší z vás tuší, jedná se o další příklad vzoru Template Method. Voláním privátní metody setClear po úspěšném uložení objektu nastavíme na false příznak "změněn" (IsDirty) a "nový objekt" (IsNew). Jestliže byl ukládán objekt, u nějž bylo vyžádáno smazání (ObjectState=ObjectState.Discarded), je nastaven příznak IsDeleted voláním chráněné metody SetDeleted na true.

Metoda Discard slouží ke zrušení objektu, přesněji řečeno k převedení objektu do stavu ObjectState.Discarded - pokud je objekt v tomto stavu a dojde k uložení objektu, metoda DoInternalSave buď záznam v databázi fyzicky vymaže (DELETE) nebo do databáze uloží stav ObjectState.Discarded (UPDATE). Metoda Discard pouze zkontroluje, zda nepracujeme nad smazaným objektem (IsDeleted=true), u nějž opakované rušení nemá smysl, a jestliže tomu tak není, nastaví objektu stav ObjectState.Discarded a označí objekt voláním metody SetDirty jako změněný.

Chráněnou statickou metodu SaveCollection používají odvozené třídy pro ukládání objektů ve svých kolekcích. (vztah agregace nebo kompozice). Výhodou je, že v odvozených třídách nemusí být stále stejný a otravný cyklus foreach, který se liší jen typem iterovaného objektu.

Metody DoInternalLoad a DoInternalSave jsme již zmiňovaly  - jsou to "sloty" používané odvozenými třídami k zavedení vlastní aplikační logiky do schématu vysokoúrovňového scénáře. Bázovou implementaci metody DoInternalLoad přijímající řádek s daty objektu mohou zavolat odvozené třídy, jestliže chtějí nahrát stav objektu (ObjectState) bez zbytečné duplikace kódu - obnovení a ukládání hodnot vlastních specifických vlastností je samozřejmě plně v režii odvozených tříd. Metoda DoInternalLoad bez argumentů ani metoda DoInternalSave nejsou abstraktní, i když by abstraktní být mohly - v business vrstvě ale občas máme třídy, u nichž nemusíme (nechceme) psát perzistenci a proto mají metody v bázové třídě prázdné tělo, abychom nebyli nuceni zcela zbytečně ve více odvozených třídách poskytovat symbolické "prázdné implementace".

Metodu Init mohou odvozené třídy použít pro vlastní inicializační kód (vytváření kolekcí a přihlašování jejich událostí atd.) - příklad uvidíte v pokračování spotu.

Metoda SetDirty nastavuje příznak "změněn oproti datům v databázi" - příznak nemá význam pro objekty pro objekty bez perzistence a pro smazané objekty.

Metoda CheckEquals porovná předané objekty - jestliže se objekty nerovnají, je objekt označen jako změněný. Jak asi tušíte, metodu volají odvozené třídy v set sekci svých vlastností (CheckEquals(oldValue, newValue)) a jsou tak zbaveni nutnosti reagovat na výsledek porovnání a ukládat si vždy každá sama za sebe příznak "jsem změněn". Když uživatel zmáčkne tlačítko uložit na formuláři a my data z formuláře přeneseme do objektu, metoda CheckEquals zajistí, že objekt bude označen jako změněný jen tehdy, pokud uživatel opravdu nějaké změny na formuláři provedl (třeba vybral jinou hodnotu v listboxu). Výhody jsou zřejmé, kód na formuláři je stále týž - pouze "tupě" přenáší data ze vstupních prvků formuláře do vlastností business objektu a ten si již potutelně a sám na úrovni předka ošetří, zda nově předané hodnoty vyžadují uložení, nebo ne, což může nastat, když uživatel z pouhého rozmaru klikne na tlačítko uložit a přitom si detail objektu celou dobu jen prohlíží.

Metoda TriggerLoad iniciuje nahrání objektu, jestliže objekt ještě nebyl nahrán, nejde o nový objekt a také nesmí jít o smazaný objekt. Metodu volají odvozené třídy při přístupu k jakékoli vlastnosti nebo metodě objektu (vzory Lazy Load, Ghost).

Význam dalších chráněných a privátních metod byl již myslím dostatečně osvětlen v předchozím textu při výkladu veřejného rozhrani, takže se nebudu opakovat.

Rozhraní IPersistable vyjadřuje minimální nárok, který musejí splňovat všechny objekty ukládající a obnovující svá data z/do perzistentního úložiště - výhodnou výchozí a závaznou osnovu realizace rozhraní poskytuje třída BusinessObjectBase.

Z enumarace ObjectState pro vyjádření základních stavů objektu prozatím nepoužívame stav InActive - význam ostatních stavů by již vám měl být po přečtení spotu dostatečně zřejmý.

Příště si ukážeme vzorovou implementaci třídy, která dědí z BusinessObjectBase.

Včera mi Vilém Málek nareportoval zákeřnou chybu v DasBlogu, která některým z vás mohla způsobit problémy při psaní komentářů a posléze i zcela znemožnit přístup na blog.

Nejdříve jsem zkusil nasadit novou verzi DasBlogu, ale tím jsem paradoxně problém jen zhoršil - v release dokumentu byla popsána asi je polovina kroků potřebných pro úspěšný upgrade, takže jsem vše ladil za pochodu a nakonec jsem musel najít chyby v stávající verzi a zkompilovat svoji vlastní verzi. Snad funkční, ale zdaleka ne dokonalou. :( Asi si nějaký blogovací engine opravdu vytvořím sám.

Podle mého testování je teď už vše v pořádku, pokud ale na nějaký problém narazíte, prosím napište mi přímo na mail reneATrenestein.net.

Viléme, ještě jednou díky!

BTW: DotNetHosting, na kterém momentálně běží moje doména, mohu zatím jen chválit. Reakce administrátora jsou okamžité, takže včera výpadek trval naštěstí jen velmi krátkou dobu. Stejně rychlé reakce na ohlášený problém, jak jsem si už stačil vyzkoušet, má DotNetHosting dokonce i o víkendu.

Nikdo z vás se nepokusil o odpověď, možná proto, že jsem nenabídl šampaňský jako u přechozí hádanky. Takže vás nebudu dál napínat, autorkou je Marina Cvetajevová, o níž a o sobě napsal kníže básníků R.M.Rilke v elegii pro Marinu tyto neskromné verše:

Vlnám jsme, Marino, mořem, hloubce jsme
Marino nebem!
Zemi jsme zemí a tisíckrát jarem, jsme skřivan,
Marino,
jenž píseň vyvřelou dál vrhá v neprůzračnost.

"Po delší prodlevě vychází další článek o návrhu aplikací s využitím jazyka UML. Místo zbytečných omluv za dlouhou a neplánovanou odmlku snad čtenáře potěší informace, že se napříště budu věnovat i konstrukcím jazyka UML nově přidaným ve verzi 2.0. Tématem tohoto článku je vysvětlení elementárních pojmů, jejichž znalost je nezbytná při návrhu diagramu tříd. " Pokračování na Interval.cz.

Stáří se může projevovat inkontinencí, což okolí díky nějakým super hygienickým vložkám, co vám dají křídla, ani nezpozoruje, ale hlavně, jak jsem dlohodobým výzkumem ve svém okolí na reprezentativním vzorku zjistil, sníženou nebo nulovou schopností ovládat běžnou spotřební elektroniku, což je diagnóza, se kterou si ani spammeři nevědí rady a na můj dotaz jich pár poslalo obratem jen nabidku na tradiční moderní všelék "Buy cialis, viagra, You will be able to penetrate deeper ". Fakt díky za osvětu, ale občas i senioři nechtějí být jen hlubinnými průzkumníky dávno propátraných a opuštěných šachet a potřebují krev napumpovat jinam. Potřeboval bych pro ně spíš syntetizovat nějaký derivát s erektivní složkou pro mozkovou kůru a s dlouhodobým účinkem. S vašimi protekčními kontakty na farmaceuticko-alchymistické koncerny to určitě bude hračka.

Dneska jsem si několikrát kontroloval vlhkost svého spodního prádla, jakožto další symptom mého předčasného stáří, protože jsem zjistil, že mám potíže s ovládáním spotřební elektroniky i já. Jen nevím, jestli je chyba na mé straně. Představuji si to nějak takhle. Senior Marketing Specialist v jedné nejmenované firmě na spotřební elektroniku, říkejme ji třeba Jessica, která se na své místo vypropracovala tvrdou prací per vaginam, se rozhodla, že konečně všem ukáže, jak její ložnicová kreativita častým pobytem na zásadních poradách sublimovala do nového koncepčního přístupu k modelovému spotřebiteli dlouhodobě probíraném pod kódovým a neredukovatelným popisem "idiot, co se bojí přemíry našich tlačítek na dálkových ovladačích a vytěžuje naše nadějné zárodečné Venuše v prodejnách spotřební elektroniky zbytečnými dotazy ("hele, jaky tlacitko mi nahraje estrádu na Nově a jaký horor na Primě, tuhle jsem se splet, chtel jsm vidět nějakou novou další originální píseň Vondráčkový o jejím novym věčně panenskym extempore na Copa Cabaně, ale místo toho mi video nahrálo nějaký horor s příšernejma vyžilejma monstrama, co vypadala jen o málo líp než moje stará, když si dá obrannej trojitej vojenskej maskovací make-up, takže jsem se dost bál, a asi až kurva po hodině mi došlo, že to Vondráčková bejt nemůže, protože pořád nevidim žádný silikonový prsa, na což jsem expert, páč už jsem prozkoumal dost natürlich přírodních dívek Blesku, a že ani ten neartikulovanej řev nevystihuje úplně přesně intonaci a frázování naší slavice, mám sluch a vkus přeci ne. Ale ještě předtím, než mi došlo, že nekoukám na estrádu, jsem se nejdřiv lek, že mojí slavici honí v nějaký nový ostřejší reality show, jako jsou ti Vyvolení a nějakej jejich velkej Bratr, ten hodně vostrej namyšlenej intelektuální hajzl Rejžek, co si pořád asi myslí, že naše všemi milovaná umělkyně je novou geneticky vylepšenou a sadističtější inkarnací otce Grebeníčka, nebo možná taky že je jenom žijícím kmotrem Mafie s vražedným pseudonymem Helena, to si asi nejni ještě v tyhle věci uplně jistej."). Dotazy kvůli své složitosti musejí být eskalovány od našich vyškolených asistenek obchodu přímo na First level support, a pak do hi-tech development centra, které se celé dny snaží řešit problém, jak může prostý člověk postmoderní éry bezchybně odlišit při volbě nahrávaného programu žádaná a skutečná normalizační monstra od monster neskutešných a falešných. Proto Jessica navrhla pro začátek experimentálně vylepšit ovládání spotřebičů a to tak, že se zredukuje počet tlačítek a většina z nich se bude chovat jinak, když je podržíme 1s, unikátně jinak, když je podržíme 2s a úplně jinak, když se jich jen tak drobounce a jemňoučce heboučce dotkneme. Jessica sice chtěla, aby tlačítka úplně jinak reagovala na slintání nad silikonovými implantáty, ale to již vývojový team nedokázal spolehlivě realizovat. Nikdo sice nepochopil, v čem je nové ovládání lepší, ale Jessica všechny uzemnila argumentem, že vymyslela včera v noci, navíc v nové a myšlenkami osvícené poloze z Kamasútry a při oduševnělém orálním spojení s VicePrezidentem, zcela originální cool slogan doprovodné kampaně podpořené nabídkou výhodné půjčky od renomované finanční společnosti Provident Financial a zabírající stoprocentně na prosťáčky. "Méně tlačítek je vždy jen s námi za stejné prachy více tlačítek"! Její kolegové slogan doprovodili frenetickým potleskem a nadšeným hýkáním, což je, jak vědí jen zasvěcenci, někteří výše postavení členové zednářské lóže a celý investigativní tým připravující Občanské Judo, nejvyšší akustická forma korporátního souhlasu při strategickém rozhodování. A challenge je challenge, co se dá dělat, z něj má jeden ze svých posledních orgasmů i stařičký předseda představenstva.

Konec vsuvky a podívejme se na výsledek extravaginální tvůrčí práce Jessiky. Dneska jsem nevěřil, když jsem si četl manuál k autoradiu Clarion. Spousta tlačítek se opravdu chová jinak, když je podržíte 1s, jinak, když je jen zmáčknete a občas pro spuštění nějaké méně použivané funkce musíte ťapat na tlačítko 2s. Kdo si tohle zapamatuje, je velmistr pro školení inovací ve spotřební elektronice a vydělá v nové době solidní peníze nezbytnými konzultacemi v domácnostech.

Kromě rádia mám špatnou zkušenost i s neergonomickým ovladačem k DVD přehrávačí Sencor nebo k videu Sony. Přijde mi jako kdyby výrobce tlačítka rozmístil podle toho, jak je náhodně vylosovalo jeho imageové oddělení z balíku všech funkcí, který dodalo technické oddělení.

Poučení na dobrou noc: Prokletím našeho věku je, že inovace musí být, i když třeba vagina Jessicy, jakožto seriový výrobek, se bez jakékoli evoluce už docela dlouhou dobu obešla.

Tak zase jedna exkurze k literárním láskám. Prozradím jen, že autorka veršů je žena - cizinka s pohnutým osudem, žijící nějakou dobu v Čechách. To, že když si vzpomenu na tyto verše, je podle mé ženy spolehlivě barevný lakmusový indikátor počínající opilosti, vám asi nepomůže, alespoň ale znáte důvod, proč jsem vybral právě je. Do všech koutů rozlezlý stesk, touha po ztraceném a přitom nikdy nehledaném, jen tušené ozvěny Kazatelovy marnosti, uhrančivé zaříkání života, hravá rozmarnost ... že se člověku ani nechce z tohoto rozpoložení střízlivět.;)

Pořád se někdo ztrácí: byl tu zatím -
dál je svět bez něho
Jednoho dne se i já takhle ztratím
z povrchu zemského

Co rve se, ve víru se točí,
zapadne v nepaměť.
I něžný hlas, i mé zelené očí,
i vlasy mé jak měď.

A svět potrvá dál, s vezdejším chlebem
a ve své jistotě.
Jako bych nikdy, pod nižádným nebem
nebyla v životě.

Já, rozmarná jak dítě - hned se hněvá,
hned radost má, i strach,
já, milující čas, kdy v krbu z dřeva
se stává žhavý prach,

violoncello, keře jako hříva,
a zvony nad hlavou...
Já, která patřím, skutečná a živá,
na zemi laskavou.

Od vás všech (proč, když v ničem neznám míru,
si mám klást otázku,
kdo cizí je, kdo můj) chci vaši víru.
A prosím o lásku.

Za moji pravdu ano-ne; ať říct vám
ji smím. Dny, nocemi
mě za to milujte, že smutná bývám
a dvacet let je mi.

za činy jak voda bez břehů -,
bláznivý ptačí vzlet,
za pravdu, za hru, za bezuzdnou něhu
a příliš hrdý vzhled.

za to, že urážky (s čím chcete přijďte)
pohřbívám do země ...
Poslyšte! - I za to, že umřu, viďte,
už milujete mě.

Sešlo se mi pár různorodých informací, které nevydají na celý spot, ale připadají mi důležité nebo zajímavé, takže je všechny spojím alespoň do tohoto "pel mel spotu".

Nejprve k blogu.

1. Komu chybí měsíční archiv spotů podobný tomu, co byl v .TEXTu, už nemusí truchlit. V pravém navigačním sloupci naleznete měsíční archiv.
   
2. Jak jste si asi již všimli, kvůli novodobému moru jménem komentářový spam jsem zapnul u komentářů povinné zadání číselného kódu z obrázku.
   
3. Pár z vás si stěžuje na malé okno pro psaní komentářů. Vězte že na odstranění problému se usilovně pracuje ;). Přesněji řečeno, postupně změním celý layout blogu, ten současný mi ani po úpravách nevyhovuje.
   
4. Pokud  mi chcete sdělit něco důležitého nebo zajímavého, tak kontakty na mě naleznete nově v pravém navigačním sloupci.

Jestliže mi někdo z vás v poslední době napsal a nedostal odpověď, není to proto, že bych na odpovědi kašlal, ale někdy v té záplavě spamů i běžné korespondence mohu na nějaký důležitý mail zapomenout. Nestyďte se a napište mi znovu.

Chci ale zdůraznit, že v žádném případě už ode mě neobdržíte odpovědi na maily s technickými dotazy zaslané na moje soukromé emailové adresy. Hlavně poté, co jsem zredukoval počet svých příspěvků v odborných konferencích, začaly na moje adresy chodit maily, jejichž pisatelé ode mě chtěli rady z různých oblastí - od psaní severových ovládacích prvků přes webové služby k flashování MDA. Snažil jsem se na dotazy odpovědět a vždy jsem na konec mailu doplnil upozornění, že žádnou další radu takto přímo neposkytnu a žádal jsem každého, aby psal dále jen do konferencí, kde si jeho příspěvku může všimnout více lidí, kteří znají odpověď. Počet mailů ale stále rostl, a proto jsem se je rozhodl ignororovat, protože neznám žádný jiný účinný způsob, jak tazatele odradit. Snad moje rozhodnutí pochopíte, nejsem žádná soukromá poradna, ani nemíním suplovat support jiných firem.

Pobavilo mě, že pár nespokojených individuí mi napsalo, jak si dovoluji neodpovídat na jejich dotazy, když jsem za to placen Microsoftem. Zamyslel jsem se nad sebou, zastyděl za svou roztržitost, kvůli níž jsem zapomněl, že jsem na čestném místě výplatní listiny Microsoftu, a jal jsem se kontrolovat své konto, abych zjistil, kolik jsem si za posledni dobu nahrabal bez práce. Začal jsem také radostně uvažovat nad tím, do jakých nových akcií ten z modrého nebe spadlý balík nacpu. Avšak ani po podrobné prohlídce všech pohybů na účtu jsem nenašel žádnou příchozí platbu od Microsoftu, takže mi ruměnec z tváře zmizel a stud vystřídala nasranost, že si mi někdy dovoluje diktovat na základě svých stupidních a nepodložených domněnek, co pro něj musím udělat. Někteří lidé jsou opravdu zvláštní tvorové a podle mé skromné a ještě neverifikované hypotézy je Bůh stvořil proto, aby zkoušel naši laskavost k bližnímu, kultivovanost v chování a sebeovládání, a tedy nám pomohl dotahovat k dokonalosti vlastnosti, jež nám zabraňují řešit konflikty nadávkami či inzultací dotyčného a činí tak náš svět alespoň občas "nejlepším ze všech možných světů".

A pro nepřispívám už tak často do konferencí, jake se mnozí ptali?

1. Hlavním důvodem je čas, respektive jeho nedostatek. Více k tomuhle bodu asi nemá cenu dodávat.
   
2. Jak jsem už psal asi před rokem a půl v jednom příspěvku, myslím si, že EMWAC, jakožto konference, která pravděpdobně sdružuje nejvíce .Net vývojářů v Čechách, přestává plnit svůj účel. Proč? Když jsem se do ní přihlásil, bylo v ní tak 200 lidí a konferencí prošlo za den jen pár příspěvků. V současné době je přihlášeno přibližně 800 lidí, počet příspěvků za den silně kolísá, ale často je jich určitě několik desitek, což už je počet, při němž se více projevují chronické problémy konference.

1. Nedostatečné technické a personální zázemí - viz třeba věčné, otravné a nikdy neřešené stížnosti kvůli Reply-To hlavičce.
   
2. Absence FAQ dokumentu - začátečnící jsou v každé konferenci vítáni, ale vždy je lepší, když jsou dotazy, které se už objevily x-krát, zodpovězeny v samostatném a na konferenci nezávislém dokumentu, než když se odpověď napíše nově příchozím pokaždé znova a znova přímo do konference.
   
3. Neexistence moderátorů - každá veřejná konference by měla mít moderátory, kteří dbají na dodržování zakladní netiquette, kontrolují formát příspěvků, a upozorňují (nejen) nováčky na prohřešky. Kořením každé konference jsou OT příspěvky, jenže na Emwacu bylo dny, kdy OT příspěvků byla většina. I to je práce pro moderátory. Já jsem ten poslední, kdo by nad sebou chtěl nějaké dráby, ale taktní a trpělivý moderátor může úroveň konference jen pozvednout.
   
4. Konference by měla být rozdělena minimálně na dvě další - jedna konference by byla pro začátečnické dotazy a druhá pro pokročilé dotazy. Není příjemné se prohrabovat nediferencovanými maily, kdy v jednom mailu pisatel řeší záludnosti webových služeb a WSDL specifikace, a hned v následujícím mailu se někdo jiný potýká se základní syntaxí jazyka C#. Řešení obou dotazů je bezesporu pro oba tazatele  stejně důležité, ale myslím, že jejich příspěvky nepatří do jedné konference.
   
5. Bod, který vyplývá z předchozích bodů. Konference je nepřehledná a je v ní spousta duplicitních dotazů i odpovědí.

Update: Reakce Romana Pichlíka

Při psaní business vrstvy libovolné aplikace jste jistě narazili na následující problém, který můžeme demonstrovat na profláknutém příkladu s objednávkami a jejich položkami. Pod položkou rozumíme instanci třídy, ve které jsou uloženy informace o vybraném produktu, počtu objednaných kusů produktu a celkové ceně. Objednávka a položka objednávky jsou třídy, které jste už určitě psali tolikrát, že nemáte rádi ani jejich názvy ;)

Každá objednávka má 0..n položek a vyžádáme-li si konkrétní položku z kolekce všech položek (Items) u objednávky, která již byla uložena do databáze, musí dojít nejprve k nahrání kolekce. Je jedno, zda položky nahráváte ihned privátní metodou nazvanou třeba loadItems volanou z konstruktoru třídy Objednávka, nebo zda (a lépe) používáte zpožděné nahrávání, kdy kolekce Items je naplněna stejnou metodou teprve po prvním přístupu a konstruktory všech business objektů pouze uloží předané unikátní identifikátory (Id) a naplní své vlastnosti uloženými daty (kromě kolekcí) až po prvním přístupu k nějaké vlastnosti (kombinace vzorů Lazy Load a Ghost). Na přístupu k plnění dat objektů nezáleží, jen vždy musíte garantovat, že uživatel objektu musí  přistupovat k datům objektu, aniž by si byl vědom provedených výkonnostních optimalizací - interní impementace je i zde nedotknutelné privatissimum objektu.

Jak zjistíte v metodě loadItems, jaké položky objednávka (třída Order obsahuje? Přes datovou vrstvu spustíte dotaz, která vrátí všechny záznamy s daty pro všechny položky objednávky - parametrem dotazu je samozřejmě Id objednávky. Kruciálním problémem je ale vytvoření položek objednávky (třída OrderItem) z vrácených záznamů. Jaké máme možnosti?

1. Vytvoříme novou instanci OrderItem a předáme jí do konstruktoru její Id. Výhodou je, že třída Order není s třídou OrderItem nijak svázána a pouze jí předává její identifikátor. Velkou nevýhodou ale je to, že object OrderItem při obnovování svých dat z databáze bude znovu posílat dotaz do databáze "dej mi data pro mé Id", což nebude nijak efektivní přístup zvláště, když v objednávce budou desítky nebo stovky položek a každá z nich s opulentní rozhazovačností pošle svůj dotaz do databáze. Navíc je to zcela zbytečné, protože data již byla vyzvednuta v metodě loadItems, ale "jen" nebyly objektu OrderItem předána.
   
2. V metodě loadItems přečteme záznamy položek objednávky, vyzvedneme data ze všech sloupců a pro každou položku vyvoláme konstruktor, který akceptuje všechny vlastnosti položky. Tedy kromě Id předáme i celkovou cenu, počet kusů atd. Sice jsme se již zbavili opakovaného dotazování do databáze položkami objednávky, ale objevily se další zásadní nevýhody. Třída objednávka je zatížena zbytečnou znalostí rozhraní (konstruktoru) třídy OrderItem a při změně třídy OrderItem, jakými jsou přidání nebo odebrání vlastnosti, budeme muset provést i změny ve třídě Order. Při tomto řešení jsme se právě vydali na strastiplnou a rozháranou životní cestu,  nazývanou moderními mudrci ze softwarových pousteven ve svých písemných testamentech "Maintenance Nightmare". Stejný problém budeme mít při plnění vlastností OrderItem, navíc bychom u každé vlastnosti museli mít i set přístupovou metodu, z čehož by se měl všem autokritickým vývojářům obracet žaludek.
   
3. Třídě OrderItem přidáme konstruktor, který přijímá záznam z databáze - v případě .Net Frameworku tedy objekt DataRow. Tohle řešení sejme povinnost nést břemeno znalosti rozhraní třídy OrderItem z třídy Order, ale zanechá nás s třídami, jejichž veřejné (nebo minimálně "internal") rozhraní je zapráskáno objekty z nižších vrstev. Proč by třída měla ukazovat, že je závislá na objektech DataRow, jejichž hlavní doménou je databázová vrstva? Perzistence je u business objektů nutné zlo, ne alfou a omegou a hlavním důvodem jejich existence. Bohužel, i v mnoha složitých projektech jsou stále k vidění jen truchlivé krabičky s daty z databáze a metodami Load a Save doplněné o honosnou etiketu "business vrstva" od nějakého rekvalifikovaného outsidera s kriplovsky laděným elánem Horsta Fuchse, co se v pomatení smyslů rozhodl pomoci saturovat deficit pracovních sil na trhu s vývojáři.

Než přejdu ke cachování dat, jen drobná poznámka, abych předešel dotazům. Metoda loadItems může poslat dotaz, který vrátí jen id položek objednávky, takže se data na klienta netahají dvakrát a můj problém pak působí jen jako vykonstruovaná obsese. I v tomte případě se ale místo jednoho dotazu budete potýkat s desítkami dotazů, které vyzvedávají - většinou zcela zbytečně - data jen pro jednu instanci OrderItem. Jestliže mám k tomu příležitost, je lepší vyzvednou všechna data pro všechny objekty najednou jedním "úsporným" dotazem a přitom dovolit v případě potřeby objektu přímé obnovení dat z databáze svým separátním dotazem.

Když tedy není pro nás přijatelný konstruktor s objektem DataRow, musíme při vytváření objektu "OrderItem" sdělit, odkud může načíst svá data. Jinými slovy, objekt OrderItem musí vědět, kam mu třída Order "schovala" objekt DataRow. Proč bychom ale neefektivně každému objektu extra sdělovali, odkud může načíst svá data? Zavedeme raději jeden centrální objekt - cache na příchozí data z databáze. Pak stačí objektu OrderItem předávat jen Id jako v první variantě a přitom  využívat všech výhod cachování dat.

Co od takové datové cache požadovat?

1. Třída musí být globálně viditelná pro všechny objekty. Půjde tedy o Singleton, respektive pro webové aplikace bude vhodné použít PseudoSingleton (Thread Specific Storage).
   
2. Rozhraní, které se nemění s přidáváním dalších business tříd a které mohou používat jednotným způsobem všechny objekty. Takže chceme univerzální metody pro ukládání i vyzvedávání dat jakéhokoli objektu, ne nějaké stále bobtnající rozhraní s metodami StoreOrdeItem, StoreOrder, StoreXX, StoreXY, ... .

Zde je jednoduchá implementace třídy, která zatím splňuje naše nároky. Zobrazit kód

Myslím, že kód je sám o sobě dostatečně vypovídající, takže jen stručný komentář. Statický atribut Instance vrátí pro každý thread specifickou instanci třídy, která se pro jeden thread chová jako běžný Singleton. Metoda CloseInstance odstraní instanci třídy pro daný thread a tuto metodu je vhodné volat ve webové aplikaci na konci každého požadavku v obsluze události EndRequest v souboru global.asax. Metoda StoreData uschová předaný datový řádek (argument row) pro objekt daného typu (argument type) - metoda předpokládá, že řádek obsahuje sloupec Id, který je jednoznačným identifikátorem každého business objektu. Metoda GetData vrátí dříve uložený řádek pro typ v argumentu type a pro objekt, jehož id bylo předáno v argumentu businessObjectId. Po vrácení dat je uložený řádek odstraněn, aby nebyly vlastnosti business objektu permanentně obnovovány z dříve uložených a již neaktuálních dat.

Přístě si ukážeme, jak si u business objektů vynutit používání třídy DataCacheHelper bez duplikace kódu a rizika, že zapomenete v nově přidané třídě řádky z instance DataCacheHelper vyzvedávat, a také postupně z DataCacheHelperu vydělíme různé aspekty jeho chování, abychom umožnili rekonfiguraci DataCacheHelperu za běhu aplikace a adekvátně vyladili jeho činnost pro různé typy aplikací.