jarda jirava .net - stránky věnované .net technologii, vývoji software s pomocí .net frameworku, návrhu software a architektuře řešení konference

Jistě každý zná situaci, kdy je nutné lokalizovat aplikaci a nabídnout ji uživatelům v několika jazykových mutacích. .NET framework toto řeší velice elegantně pomocí resource souborů a ResourceManagera. V asp.net 2.0 je celé řešení velice důmyslně řešeno, kdy je možnost jít ještě dále a nabízí se tak mít lokální a globální resource soubory, o tom, jak to celé funguje napsal poměrně zajímavý blogspot také Robert Haken v článku Lokalizace snadno a rychle - explicitní lokalizace. Jak už to však bývá, ne vše je tak kulaté jak se zdá.

Je to už nějaká chvíle co byl na konferenci o .net na fóru builder.cz položen dotaz ohledně možnosti lokalizace asp.net aplikací. Tenkrát jsem slíbil, že se pokusím sepsat nějaký krátký příspěvek na toto téma a zpřístupnit tak své nabyté zkušenosti také ostatním.

O co se konkrétně jedná? Autora dotazu zajímalo, zda je možné použít k lokalizaci texty, které má umístěny v databázi. Odkazů na řešení daného úkolu se našlo hnedka několik, ale většinou se jednalo o takové řešení, které nebylo elegantní (alespoň mě se nezdálo). Převážně se taková řešení opírala o skutečnost, že je nutné explicitně provést lokalizaci daného textu z codebehind stránky tj. vytvořit si nějaký vlastní DbResourceManager a pomocí metod GetString provádět lokalizaci jednotlivých textů. Přitom je velice elegantní a dostupné řešení v asp.net 2.0, a to použítí meta značek a nebo alespoň použití explicitní lokalizace tedy uvedení této konstrukce.

property="<%$ Resources: LokalizovanyText %>"

Jaká je tedy možnost lokalizace v případě, že nechci používat resource soubory? Mám já, jako vývojář, nějakou možnost si říci, že všechny texty budou uloženy třeba v databázi a odsud se budou načítat? A to ještě pokud možno s co nejmenším úsilým, které k lokalizaci bude nutné udělat? Nebude nutné se uchýlit k nějakému vlastnímu formátu řešení lokalizace, byť by bylo sebelépe navrženo, a upustit tak od modelu, který je v současné chvíli podporován v asp.net 2.0? Nesetkám se zde s podobným problémem, který nastavá u celkové konfigurace aplikace, kdy je možné používat ConfigurationManager pouze ve spojitosti s .config souborem a přitom je občas vhodné mít konfiguraci uloženu i jinde? 

Na poslední otázky je však v souvislosti s lokalizací možné odpovědět, nikoliv. Tím řešením je napsat si vlastní ResourceProviderFactory a implementovat několik rozhraní případně dědit z tříd již existujících. To celé potom spojit v jeden funkční celek pomocí konfiguračního souboru web.config v jeho sekci globalization a to atributem resourceProviderFactoryType.

O tom, jak si napsat takový jednoduchý ResourceProvider, kterým je možné lokalizovat asp.net aplikace a vesměs pouze přepínat pomocí konfigurace mezi jednotlivými možnostmi, se rozepíšu příště.

Ač uplynul nějaký ten den od okamžiku, kdy jsem se na vlastní oči potkal s IIS7 nedalo mi to, abych nenapsal pár slov.

Vše se událo 28. února, ten den se toho událo o něco málo víc, ale o tom chci ještě napsat jeden samostatný příspěvek. Ono úterý Michal Juřek prezentoval velice pěkně přednášku na téma Introducing IIS7.0. Sdělených informací bylo dost a dost, ale jedna oblast mě zaujala, možná i proto, že i v současné době s ní (ne)úspěšně bojuji - je to konfigurace aplikace.

web.config skutečná konfigurace webu

Již nyní je umožněno pomocí souboru web.config nakonfigurovat vytvořenou web aplikaci. IIS7 jde v této oblasti ještě o další krok dál a nechává vše "v rukách" xml. Teď možná zarmoutím všechny vyznavače příkazové řádky a notepadu, ale i pro editaci xml je k dispozici grafický nástroj, kam je možné doplnit vlastní rozhraní pro uživatelské sekce. Co je ovšem důležité, že skutečně celá konfigurace aplikace může být umístěna do jednoho souboru. A tady je právě to co mě trochu trápí a s čím jsem se v současné době dokázal vypořádat.

Nevím jak vám, ale poměrně často se mi stává, že potřebuji rozlišit, zda konfiguruji aplikaci nebo web. Je mi jasné, že ten rozdíl je velice malý a i já sám si občas říkám, zda skutečně takové rozdělení, které mám na mysli je nutné a dobré. Ale jistě to znáte také, máte jisté části web.config souboru pevně dané - např. způsob autentikace. Jenže pak jsou sekce, které se liší podle toho, kde je daná instance aplikace umístěna. Co se nejčastěji mění u nás je connection string, případně definice a hodnoty umístěné ve vlastních konfiguračních sekcích.

Uložení konfigurace mimo web.config

Výše zmíněný problém nutnosti různých konfigurací se vyskytl již několikrát. V modelu, kdy bude konfigurován kompletní web, pravda nejen přes web.config, ale dá se tak předpokládat, bude potřeba konfigurace částí aplikace umístěné mimo tento soubor ještě vzrůstat. Alespoň to je můj osobní názor, který budu rád, pokud mi někdo bude chtít vyvrátit. Již nyní mám napsány providery, kteří dokáží načíst konfigurace z databáze. Přeci jen se tak jednotlivé části snáze administrují a případná změna některé části je snadnější. Pokud pak nemáte fyzický přístup k danému souboru a je nutné provést přenastavení části aplikace, je postačující zaslat příslušný extrakt xml a administrátor systému na klientově straně dokáže přes dodanou winform aplikaci provést příslušnou změnu. Zároveň s tím je možné zajistit historii takových změn i s časovým razítkem promítnutí takové změny.

Také proto mě nemile překvapilo, že se kompletní konfigurace přesunula do jednoho souboru a přibyly další sekce, které více ztíží možnost ruční editace. Ano vím, existuje grafický nástroj, ale i tak mi to nepřijde příliš vhodné - i díky možnosti zaslat klientovi nově nakonfigurovanou celou sekci.

Je nějaké řešení

Je mi jasné, že sám nejspíš nic nezmohu. Vím, že najít ten správný rozdíl mezi tím, co zůstane neměnné a co bude nutné občas změnit je obtížné a každý může mít jiné požadavky. Přesto si myslím, že v době, kdy existuje SQL 2005 Express případně jiný databázový engine by stálo za zvážení, zda jednotlivé konfigurační sekce nepřenést do tabulky - klidně stále v xml čitelném formátu, pro možnost vytvářet vlastní složitější konfigurace. Celkem si také dovedu představit, že by taková tabulka ve webové databázi byla provázána přímo s jádrem IIS a dokázala by reagovat na změny, případně hlídat časové razítko od kdy je daná změna platná a to pro všechny vytvořené a běžící webové aplikace.

Možná je můj požadavek směšný, je možné že jsem jednostranně zaměřený a vidím pouze to, co využiji sám a nevidím i druhou stranu. Přesto jsem se pokusil sepsat to, co bych od připravovaného IIS7 očekával a zároveň své pohnutky zdůvodnil. Třeba se v některé z příštích verzí potkám s navrženým řešením :-)

V kalendáři už mám poznamenán termín 19.01.2005 18:00. Den, kdy se koná třetí setkání .NET developer group 2005.

Na setkání se těším, mám pro to hnedka několik důvodů. Prvním z nich může být skutečnost, že jsem se prvních dvou setkání nemohl zúčastnit, což mě osobně mrzelo. Potom je třeba zmínit i lákavost toho, setkat se s lidmi, které znám z konferencí, případně z osobních setkání a prohodit s nimi pár slov. Přeci jen od setkání s většinou z nich uběhl už nějaký ten měsíc, a .NET i projekty v něm vypadají o poznání jinak než dříve. (To platí hlavně u mě, i když je těžké se k tomu přiznat, protože jsem si před rokem říkal, jak .NETu a programování celkem rozumím ;-) )

Samozřejmě také nemůžu zapomenout na Michala Bláhu a jeho očekávanou a avizovanou přednášku. Přeci jen psaní webových .NET aplikací mě živý, a jak takové aplikace ještě zlepšit a výkonově povznést, může být zajímavé. Obzvláště v této chvíli je to téma jak na zavolanou, jelikož se spolupodílím na vývoji aplikace, pro kterou výkon při zpracování požadavků bude jedním z klíčových faktorů.

Jen tak na okraj

Když už jsem se zmínil o lidech, které bych rád opět potkal a u kterých předpokládám, že se zúčastní. Určitě to je Martin Vobr, se kterým jsem si dobře popovídal a rád tak učiním i příští středu. Pak to je určitě René Stein, který mi otevřel oči a ač to sám zřejmě neví, ukázal novou cestu. Při společném rozhovoru jsem slyšel víc, než mi říkal a pochopil jsem to co jsem do té doby jen četl v knížkách (díky a snad budu moci poděkovat také osobně). Michala Bláhu, kterého uvidí a uslyší všichni. Snad mu zbyde čas na méně známé tváře :-) Lidičky, které mám už delší čas v kontaktech na ICQ, a i další, které potkávám v konferencích a rád bych znal jejich tvář.

Vím, nemohou přijít všichni a nemohu se poznat se všemi.

Podtitulek tohoto logu se zmiňuje o tom, že bych se zde rád věnoval střípkům z konferencí o .NETu. Dlouho jsem váhal, zda téma, které mě trklo, bude zajímavé. Ale poté, co jsem si vše vyzkoušel a napsal test, neváhal jsem.

Informace o tom, že použití reflection je pomalejší, je obecně známý fakt, se kterým jsem pracoval. Ovšem výsledky měření, které jsem provedl, mě celkem překvapily. Ale vrátím se na samý začátek, ať nevytvářím závěry dřív, než napíšu podstatu.
Jeden z dotazů do konference zněl, zda se dá ze zadaného jména proměnné, k této přistoupit a změnit její hodnotu.

On ten dotaz zněl ještě přesněji. Což mě vedlo k odpovědi, proč raději nepoužít pole. Tomas Rampas však neváhal a odpověděl, přesně podle přání dotazujícího. V ten okamžik mě napadlo, že ve svých programech používám reflection, a uživatelsky definované atributy. Zatím jsem však neprováděl měření, kterým bych zjistil k jak velkému zpomalení, díky tomuto přístupu, vše vede. Takže jsem neváhal a zkusil napsat pár tříd, na kterých jsem si chtěl ověřit onen obecně známý fakt.

Definice testování

Ač jsem absolvoval nějaké pokusy (jistě je znáte i vy ze školních škamen), jedna z mála věcí, která mi utkvěla v paměti je, že se má testovat na stejném vzorku dat. Takže jsem definoval množinu, vlastně třídu, která bude mít možnost uchovat sto hodnot typu int. K těmto hodnotám se půjde dostat pomocí metod int GetValue(int index) a void SetValue(int index, int value). Pro lepší porovnání jsem pak přistoupil ještě k možnosti, že třídy, které používají reflection, si mohou informativní údaje uschovat do HashTable. Co mě napadlo až při pohledu na kód zaslaný do příspěvku, že vytvořím ještě třídu, která bude obsahovat property, místo fieldů.

Jak jsem měřil

Mám připravené čtyři třídy, které jsem pojmenoval TestArray, TestField, TestProperty a TestPropertyHash. Každá obsahovala zmíněné dvě metody. Přistup k hodnotám pole byl realizován s otestováním na přetečení a přistupu nad/pod mez pole. Ostatní tři třídy přistupovaly ke svým property/fields pomocí reflection. Veřejné proměnné byly pojmenovány Cislo0 .. Cislo99. Z předaného čísla indexu byl sestaven název proměnné a pomocí reflection získáno PropertyInfo/FieldInfo. Rozdíl byl u testování TestPropertyHash, kdy se nejdříve zjišťovala přítomnost informací v tabulce a až poté jsem případně zjišťoval potřebné informace.
Po několika měřeních jsem zjistil, že simulovat aspoň trochu reálné prostředí zřejmě nepůjde, neboť naměřené hodnoty jsou příliš malé pro posouzení náročnosti. Takže jsem nastavil počet průchodů přes jednotlivé operace na poněkud vyšší hodnoty, než které se mohou (snad) reálně vyskytnout v aplikaci. I když ani takové chování se nemůže nikdy vyloučit. Takže nakonec jsem přistoupil k následujícím počtům.

• Start počítání času
• Vytvoření objektu celkem 20x
• Počet zapsání a opětovné vyzvednutí hodnoty každé proměnné v jednom vytvořeném objektu 50x
• Ukončení počítání času

Toto celé pak bylo zopakováno pro každou testovanou třídu 15x. Vše po dvou hodinách běhu počítače na kterém jsem v té době neprováděl žádné operace.

Malé doplnění k měření

Jelikož jsem byl při znalosti naměřených hodnot zvědavý, co s metodami GetProperty a GetField udělají zapsané BindingFlags, pustil jsem měření ještě jednou s uvedením těchto Flagů BindingFlags.Public | BindingFlags.Instance. V tabulce jsou tato měření označena jako "O".

Výsledky měření

Jak už jsem se zmínil v úvodu, měřeními jsem byl celkem překvapen, i když musím říci, že se jedná o trošku přehnané hodnoty průchodů, a ať jsem vzpomínal jak chtěl, nenarazil jsem na případ, kdy bych něco takového ve svých aplikacích prováděl. Každopádně je to zajímavé a pokud někdo uvažuje o co nejrychlejším kódu, určitě bych doporučoval se reflection vyhnout. Měření ukázalo, že nejpomalejší přístup je pomocí reflection, která získává informace o veřejných Fieldech. Za ní se v těsném závěsu drží přístup k Property. O něco lepší je přístup, kdy se použije k uchování informací Hashtable, která pak udržovala celkem konstantní čas přístupu a je to asi nejrozumější volbou, pokud je potřeba použít reflection. Samozřejmě nejrychlejší cestou je pak přímý přístup k poli, který měl v prvních chvílích až nezanedbatelné měření. Ostatně kvůli tomu, jsem zvedal "laťku" výše, abych se ujistil, že takové měření nemá spíše statistickou chybu. Jak měření dopadla, se můžete přesvědčit v následující tabulce.

Ještě je potřeba zmínit, že pro měření jsem nakonec využil kódu, který uveřejnil Petr Lazecký.

Tabulka naměřených hodnot

	Array O	Field O	Property O	PropertyHash O	Array	Field	Property	PropertyHash
1.	0,012859456	14,52278656	8,119284993	3,790104608	0,01253651	13,982752	8,30993995	3,31640418
2.	0,011206173	14,44983762	8,554286648	3,439473173	0,011182706	14,10884847	8,185773611	3,274529863
3.	0,010985754	13,98355406	8,173504454	3,165731119	0,011029614	14,14912007	8,3745666	3,262086382
4.	0,011520179	13,81221636	8,388321141	3,229624156	0,010975697	13,93663608	8,400916318	3,455275461
5.	0,010967595	13,6163504	7,940935789	3,147346939	0,010981005	13,9495827	8,087749979	3,135475598
6.	0,011145551	13,83192249	7,90464654	3,178728861	0,010981843	14,60432401	8,161623894	3,274396606
7.	0,011411506	13,58849072	7,942665059	3,167312047	0,011639468	14,41323045	7,990731224	4,447815854
8.	0,011212878	14,40057773	7,937816398	3,512432725	0,0121711	14,40095934	8,592995478	3,496401638
9.	0,011254503	13,61583302	7,928621375	3,168193164	0,011033525	14,45914774	9,120829044	3,327205832
10.	0,010959493	13,48283371	7,859824363	3,134714608	0,012849398	13,82637821	8,273673889	3,491689586
11.	0,011336357	13,82340297	7,903663454	3,147873543	0,010954744	15,38235139	8,636580348	4,733472271
12.	0,011231874	13,56582778	7,937909986	3,149191587	0,011520179	13,96755789	8,301080724	3,216261005
13.	0,011789767	13,5769588	7,930314328	3,148871435	0,010970109	13,90357601	8,08478843	3,143627752
14.	0,011563481	13,60198321	7,920364739	3,156153086	0,011094427	13,54703936	8,445257149	4,925186022
15.	0,011142757	13,57030321	7,905241867	3,168578409	0,012306033	13,66658137	8,025275279	3,137395675
Avg.	0,011372488	13,82952524	8,023160076	3,246955297	0,011481757	14,15320567	8,332785461	3,575814915

Poohlédnutí se za výsledkem

Myslím, že k tomuto není třeba dodávat jakýchkoli slov. Čísla jsou jasná. Naměřenými hodnotami jsem byl překvapen víc, a očekával jsem o hodně menší rozdíly. Obzvláště mě pak překvapil rozdíl v přístupu k Property a Field. Můj osobní předpoklad byl spíše opačný na druhou stranu je to jen dobře, neustále zjišťuji, že se mám co učit a co zkoušet.

Budu rád, za jakékoli Vaše připomínky, které mohou pomoci nejen mě, ale i ostatním.

Nedávno jsem v jednom příspěvku v konferenci o .NET na serveru builder.cz přislíbil, že dám dohromady co možná nejvíce příspěvků uveřejněných v tomto fóru.

Týden se s dalším týdnem sešel a mám hotovo. Přiznávám, dalo mi to trochu víc práce než jsem očekával, převést vše do jednoho formátu. (Tímto nedoporučuji střídat emailové klienty.) Ale povedlo se.

Soubory archivu

• První soubor [1.4MB] obsahuje příspěvky od 3.9.2001
• Druhý soubor [2.5MB] obsahuje příspěvky od 16.10.2003

Přípěvky nejsou nikterak tříděné, a myslím, že jsem za celou dobu nepoužil mnohokrát tlačítka DELETE (odchylka cca 1000 příspěvků).
Zároveň se zveřejněním jsem uvažoval, že napíši pár slov a jmen o kvalitních přispěvatelích a na které odpovědi se tak více zaměřit, ale neudělám to. Z jednoho prostého důvodu, určitě bych nevypsal všechny, a na někoho bych zapoměl, kdo si zaslouží, nejen můj, obdiv. Což bych nerad. Nebudu se ovšem vůbec zlobit, spíše naopak, pokud tak učiní někdo z Vás, komu tento off-line přehled pomůže, a komu pomohly odpovědi dotyčného.

Co říci závěrem. Ne, nebude to žádné moudro, pouze vlastní zkušenost. Je dobré vědět, že se mám koho zeptat, na koho se obrátit. Když však na něco přijdu sám, těší mě to dvojnásob a naučím se při tom mnohem víc.

Informace pro Ty, kteří pracují s regulárními výrazy a chtějí sledovat poslední dění na této scéně. Byl založen nový blog prostor a to na adrese http://regexblogs.com/.

Mohu si jenom přát, ať na tomto blogu najde každý co se mu líbí a je k užitku, stejně tak jako ostatní blogy zaměřující se na určité téma. A protože sám občas potřebuji použít nějaký ten regulární výraz, těším se na uveřejnění dobrých tipů a triků.