Milφ Φtenß°i,

 

vφtßm vßs u zbrusu novΘho serißlu, kter² se bude zab²vat momentßln∞ nejmodern∞jÜφm nßstrojem pro tvorbu .NET aplikacφ, a sice Visual Basicem .NET. Serißl je urΦen zejmΘna pro zaΦßteΦnφky, no v∞°φm, ₧e bude u₧iteΦn² rovn∞₧ pro pokroΦilΘ u₧ivatele a takΘ softwarovΘ profesionßly, kte°φ budou chtφt povznΘst formu v²voje sv²ch aplikacφ na .NET ·rove≥. SpoleΦn∞ tak prozkoumßme vÜechny äzßkoutφô novΘho programovacφho jazyka a u₧ te∩ vßs mohu ujistit, ₧e o zßbavu budeme mφt vystarßno. Vysv∞tlφme si pou₧itφ jazyka, zp∙sob sestavovßnφ .NET aplikacφ, pou₧itφ ovlßdacφch prvk∙, zßklady objektov∞ orientovanΘho programovßnφ a spoustu dalÜφho. Cφlem serißlu je nauΦit i naprostΘ zaΦßteΦnφky budovat, pou₧φvat a udr₧ovat programovΘ aplikace pro platformu Windows. Pokud jste jeÜt∞ neprogramovali ve Visual Basicu, p°φpadn∞ neprogramovali v∙bec, nev∞Üte hlavu. I vßm se toti₧ otvφrajφ dve°e do kouzelnΘho sv∞ta .NET technologiφ. StaΦφ jenom vykroΦit...

 

 

 

 

Krom∞ chuti nauΦit se n∞co novΘho a ochoty v∞novat studiu i trochu Φasu budete rozhodn∞ pot°ebovat ty sprßvnΘ nßstroje k vaÜφ prßci. P°edevÜφm byste m∞li disponovat pom∞rn∞ v²konn²m poΦφtaΦem a odpovφdajφcφm softwarov²m zßzemφm. Co se t²Φe hardwaru, spoleΦnost Microsoft uvßdφ tuto minimßlnφ poΦφtaΦovou konfiguraci, na kterΘ by m∞l Visual Basic .NET jak₧ tak₧ pracovat. Co tedy budete pot°ebovat?

 

╖         450 megahertzov² procesor t°φdy Pentium II nebo lepÜφ,

╖         160 MB operaΦnφ pam∞ti RAM,

╖         3,5 GB volnΘho mφsta na instalaΦnφm disku a dalÜφch 500 MB volnΘho mφsta na systΘmovΘm disku,

╖         mechaniku CD-ROM, p°φpadn∞ DVD-ROM,

╖         a obrazovkovΘ rozliÜenφ alespo≥ 800x600 obrazov²ch bod∙ p°i 8bitovΘ hloubce barev.

 

I kdy₧ se v mnoha materißlech uvßdφ tato konfigurace jako pom∞rn∞ dostaΦujφcφ, nenφ tomu zcela tak. Pro praktickΘ vyu₧itφ je nutno poΦφtat s daleko siln∞jÜφ ämaÜinouô. Osobn∞ bych vßm doporuΦil alespo≥ gigahertzov² procesor a nejmΘn∞ 256 megabajt∙ operaΦnφ pam∞ti. Velkou v²hodu zφskßte, jestli₧e vlastnφte kvalitnφ monitor s ·hlop°φΦkou minimßln∞ 17 palc∙ a rozliÜenφm 1024x768 obrazovkov²ch bod∙ p°i 32bitovΘ barevnΘ hloubce. Proto₧e VB .NET obsahuje velkΘ mno₧stvφ oken, podoken, vysouvacφch oken a ohromnΘ mno₧stvφ dalÜφch nßstroj∙, kterΘ budete chtφt mφt na obrazovce, investice do v∞tÜφ plochy monitoru se zde zcela jasn∞ vyplatφ.

 

Po prozkoumßnφ hardwarovΘ Φßsti se poj∩me podφvat, jakΘ jsou nßroky novΘho Visual Basicu na softwarovΘ zabezpeΦenφ. Aby mohl VB d²chat, musφ b²t podep°en operaΦnφm systΘmem Windows 2000 nebo XP. I kdy₧ prvnφ zkuÜebnΘ verze b∞haly i pod Win9x, ostrß verze je v tomto sm∞ru nßroΦn∞jÜφ a nenφ je tedy mo₧nΘ instalovat pod starÜφ typy operaΦnφho systΘmu Windows.

 

Pomalu, ale jist∞ se dostßvßme k p°edstavenφ samotnΘho programovacφho nßstroje. Visual Basic .NET m∙₧ete zφskat v t∞chto vyhotovenφch:

 

╖         Visual Basic .NET Standard,

╖         Visual Basic .NET Professional,

╖         Visual Basic .NET Enterprise Developer

╖         a Visual Basic .NET Enterprise Architect.

 

 

Dobrß, technickΘ specifikace mßme za sebou a te∩ se m∙₧eme podφvat, na Φem stojφ celß .NET technologie.

 

 

 

VeÜkerß funkcionalita technologie .NET le₧φ na pov∞stnΘm zßkladnΘm kameni, kter² je znßm² jako .NET Framework. .NET Framework p°edstavuje prost°edφ pro v²voj a b∞h aplikacφ, p°iΦem₧ do jeho p∙sobnosti pat°φ tak°ka vÜechny operace, je₧ jsou s v²vojem a exekucφ programovΘho k≤du spjaty (alokace a dealokace pam∞ti, provßd∞nφ programov²ch instrukcφ atd.) Prost°edφ rßmce .NET Framework je tvo°enΘ dv∞ma hlavnφmi souΦßstmi: Common Language Runtime a Base Class Library. Podφvejme se, co se za t∞mito zßhadn²mi nßzvy skr²vß.

 

 

 

CLR je zodpov∞dnß za skuteΦn² b∞h aplikacφ .NET. ZabezpeΦuje vÜe pot°ebnΘ, kompilaci k≤du, jeho b∞h, alokaci pam∞ti, zprßvu proces∙ a vlßken. CLR s sebou p°inßÜφ velmi zajφmavou koncepci pro kompilaci a nßslednou exekuci programovΘho k≤du. Pokud jste pracovali s p°edchozφ verzi Visual Basicu, vφte, ₧e aplikaci jste mohli p°elo₧it jak do tzv. P-k≤du, tak i do nativnφho (strojovΘho) k≤du poΦφtaΦe. Zcela jinß je v tomto sm∞ru situace v prost°edφ .NET Framework. Kdy₧ budete kompilovat aplikaci .NET, kompilßtor nebude p°eklßdat v²sledn² k≤d aplikace do nativnφho formßtu. Mφsto toho je vÜechen k≤d standardn∞ zkompilovßn do urΦitΘ jazykovΘ mezivrstvy, kterΘ se °φkß Microsoft Intermediate Language, zkrßcen∞ MSIL (n∞kdy se m∙₧ete st°etnout i se zkratkou IL).

 

ááá

Abyste m∞li lepÜφ p°edstavu o k≤du jazyka MSIL, m∙₧ete si tento k≤d p°edstavit jako jist² druh polotovaru. Tak jako musφ b²t polotovar upraven do podoby finßlnφho produktu, tak i segment k≤du MSIL musφ b²t p°ed pou₧itφm äupravenô do strojovΘho jazyka, kterΘmu je schopen poΦφtaΦ bezprost°edn∞ porozum∞t. ┌prava k≤du MSIL do nativnφho k≤du je realizovßna prßv∞ prost°ednictvφm CLR, kterß p°i tΘto operaci vyu₧φvß slu₧eb Just-In-Time (zkrßcen∞ JIT) kompilßtoru.

 

JIT kompilßtor p°elo₧φ pot°ebnΘ k≤dovΘ instrukce, vyhradφ pro n∞ prostor v pam∞ti a spustφ je. Jestli₧e v budoucnosti programovß logika poruΦφ, ₧e je t°eba pou₧φt dalÜφ instrukce programu, je op∞t zavolßn JIT kompilßtor, kter² p°elo₧φ dalÜφ k≤d do jeho nativnφ podoby, a tak zabezpeΦφ spuÜt∞nφ ₧ßdan²ch programov²ch instrukcφ.

 

Situaci sestavenφ .NET aplikace a jejφ exekuce znßzor≥uje obr. 1.

 

 

Obr. 1 û SchematickΘ zobrazenφ sestavenφ a zp∙sobu b∞hu .NET aplikace

 

Proto₧e je vÜechen k≤d nejd°φve p°eklßdßn do MSIL k≤du, mohou r∙znΘ aplikace, vytvo°enΘ v r∙zn²ch programovacφch jazycφch standardu .NET (Visual Basic .NET, Visual C# .NET a Visual C++ .NET) spoleΦn∞ komunikovat. Z uvedenΘho d∙vodu musφ vÜechny kompilßtory .NET jazyk∙ vyhovovat urΦit²m pravidl∙m, kterß definuje Common Language Specification (CLS). Tφm je garantovßna mezijazykovß kompatibilita.

 

 

 

BCL, nebo jednoduÜeji °eΦeno knihovna zßkladnφch t°φd, p°edstavuje robustnφ kolekci t°φd, typ∙, rozhranφ a objekt∙, kterΘ m∙₧ete p°i v²voji vaÜich vlastnφch aplikacφ vyu₧φt. P°φchu¥ koncepce objektov∞ orientovanΘho programovßnφ je v BCL p°φtomna v daleko v∞tÜφ mφ°e, jako kdykoliv p°edtφm. Prakticky na ka₧dΘm kroku v²voje mßte do Φin∞nφ s t°φdami, jejich instancemi (objekty) a popravd∞ °eΦeno, ani si tuto skuteΦnost p°φliÜ neuv∞domujete. pro zachovßnφ po°ßdku je BCL Φlen∞na do tzv. jmenn²ch prostor∙. Pod pojmem jmenn² prostor lze chßpat urΦitou mno₧inu sp°φzn∞n²ch funkcφ. VÜechny jmennΘ prostory jsou organizovßny hierarchicky, od zßkladnφ ·rovn∞, kterou p°edstavuje jmenn² prostor System a₧ po dalÜφ a dalÜφ v∞tv∞, kterΘ ukr²vajφ dalÜφ kolekce jmenn²ch prostor∙. Pokud budete vyvφjet standardnφ äokennφô aplikaci pro Windows, v hojnΘ mφ°e vßm poslou₧φ t°φdy jmennΘho prostoru System.Windows.Forms. Jak si m∙₧ete z uvedenΘho zßpisu jmennΘho prostoru vÜimnout, jestli₧e se chcete dostat k dalÜφm (vno°en²m) jmenn²m prostor∙m jednoho jmennΘho prostoru, pou₧ijete operßtor teΦka (.).

 

Abyste ovÜem nemuseli v programovΘm k≤du neustßle zadßvat pln∞ kvalifikovan² nßzev jmennΘho prostoru, m∙₧ete si situaci zjednoduÜit pou₧itφm klφΦovΘho slova Imports a zadßnφm k²₧enΘho jmennΘho prostoru. P°edpoklßdejme, ₧e pracujeme s jmenn²m prostorem System.Windows.Forms.Form. Tento nßm umo₧≥uje p°istupovat k vlastnostem a metodßm t°φdy Form, ze kterΘ se tvo°φ samotnΘ objekty formulß°∙. Abychom ale nemuseli v₧dy zadßvat tento dlouh² nßzev jmennΘho prostoru, vlo₧φme odkaz na jmenn² prostor takto:

 

Imports System.Windows.Forms

 

A nynφ se na formulß° budeme odkazovat jenom pomocφ klφΦovΘho slova Form.

 

 

 

 

Zm∞ny v stavb∞ aplikacφ, kterΘ p°inesl .NET Framework, jsou vskutku revoluΦnφho charakteru. P°edn∞, zßkladnφ stavebnφ jednotkou se stßvß tzv. assembly. Assembly lze chßpat jako jistou kolekci programovΘho k≤du, programov²ch zdroj∙ a metadat. Ka₧dß assembly obsahuje manifest, kter² popisuje jejφ vnit°nφ strukturu. Manifest obvykle poskytuje informace o nßsledujφcφch skuteΦnostech:

 

╖         identifikaci assembly, kterou tvo°φ jejφ jmΘno a Φφslo verze,

╖         seznamu typ∙ pou₧it²ch v assembly,

╖         seznamu jin²ch assembly, kterΘ danß assembly vy₧aduje ke svΘ Φinnosti,

╖         a koneΦn∞ o bezpeΦnostnφch na°φzenφch pro popisovanou assembly.

 

V tΘto souvislosti je d∙le₧itΘ si uv∞domit, ₧e ka₧dß assembly m∙₧e obsahovat pouze jeden manifest.

 

Assembly dßle tvo°φ jeden nebo i n∞kolik modul∙, kterΘ obsahujφ programov² k≤d .NET aplikace a takΘ metadata, popisujφcφ tento k≤d. VeÜker² programov² k≤d, kter² assembly obsahuje, se nachßzφ ve form∞ MSIL k≤du. P°φklad jednoduchΘ assembly m∙₧ete vid∞t na obr. 2.

 

 

Obr. 2 û Struktura jednoduchΘ assembly

 

 

 

Common Type System je odpov∞dn² za typovou kompatibilitu .NET aplikacφ. Jak ji₧ dob°e vφte, v procesu kompilace aplikacφ dochßzφ k p°ebudovßnφ programovΘho k≤du do podoby MSIL. Toto se d∞je u vÜech programovacφch jazyk∙ platformy .NET, ne jenom u Visual Basicu. Chceme-li hovo°it o kompatibilit∞ na nφzkΘ ·rovni, musφ b²t n∞jak²m zp∙sobem upraven² i typov² systΘm vÜech aplikacφ. V k≤du MSIL jsou vÜechny odpovφdajφcφ si datovΘ typy jednotliv²ch programovacφch jazyk∙ .NET vyjßd°eny ve stejnΘ podob∞. Uka₧me si p°φklad. Visual Basic .NET i Visual C++ .NET mohou pracovat s datov²m typem Integer (ve VB je oznaΦenφ typu Integer, ve VC++ int). Aby byla zabezpeΦenß jednotnost, p°i p°ekladu aplikacφ do MSIL k≤du jsou vÜechny v²skyty datovΘho typu Integer (resp. int) nahrazeny jednotn²m systΘmov²m typem System.Int32. Podobn∞ je to i u ostatnφch datov²ch typ∙.

 

CTS tvo°φ dv∞ skupiny typ∙:

╖          hodnotovΘ typy

╖          referenΦnφ typy

 

á á

K hodnotov²m typ∙m pat°φ:

╖         zßkladnφ datovΘ typy (Integer, Boolean, Char, ...)

╖         u₧ivatelsky definovanΘ typy (struktury)

╖         enumeraΦnφ (v²ΦtovΘ) typy

 

K referenΦnφm typ∙m pat°φ:

╖         t°φdy

╖         rozhranφ

╖         pole

╖         delegßti

╖         ukazatele

 

Pro dokonalejÜφ probßdßnφ problematiky hodnotov²ch a referenΦnφch typ∙ bychom si m∞li pov∞d∞t o tom, jak se s t∞mito typy zachßzφ v operaΦnφ pam∞ti poΦφtaΦe. JeÜt∞ p°edtφm ovÜem musφte porozum∞t dv∞ma zßkladnφm pojm∙m z oblasti pam∞¥ovΘho managementu. Jde o pojmy zßsobnφk (stack) a hromada (heap).

 

Zßsobnφk si m∙₧ete p°edstavit jako oblast pam∞ti, kterß je vyhrazena pro b∞h jistΘ programovΘ aplikace. V okam₧iku, kdy je jako odpov∞∩á na vzniklou udßlost volßna programovß funkce, jsou vÜechny prom∞nnΘ, kterΘ tato funkce pou₧φvß umφst∞ny na zßsobnφk. Kdy₧ je volßna dalÜφ funkce, tak i jejφ prom∞nnΘ jsou ulo₧eny na zßsobnφk, ovÜem änadô p°edchozφ ulo₧enΘ prom∞nnΘ. Zßsobnφk pracuje na principu LIFO (angl. Last In First Out, tedy poslednφ dovnit°, prvnφ ven). To je ve skuteΦnosti hlavnφ princip fungovßnφ zßsobnφku. Podle tohoto principu je mo₧nΘ ze zßsobnφku vybφrat jenom ty prom∞nnΘ, kterΘ tam byly ulo₧enΘ naposled. Jestli₧e volanß funkce ukonΦφ svou Φinnost, vÜechny jejφ prom∞nnΘ jsou odstran∞ny ze zßsobnφku. Jinak °eΦeno, pam∞¥, kterou tyto prom∞nnΘ okupovaly, je uvoln∞na a p°φstupnß pro dalÜφ operace.

 

Oblast pam∞ti, kterß je rezervovßna pro tvorbu objekt∙, se naz²vß hromada (heap). Tato oblast je pod sprßvou Common Language Runtime, kterß za tφmto ·Φelem vyu₧φvß slu₧eb pokroΦilΘ sprßvy pam∞ti oznaΦovanΘ jako Garbage Collection (GC). áá

 

Hodnoty p°i°azenΘ do hodnotov²ch typ∙ jsou uklßdßny v₧dy na zßsobnφk. Naproti tomu, u prom∞nn²ch referenΦnφch typ∙ je situace zajφmav∞jÜφ. Zde je samotn² objekt ulo₧en² na hromad∞, avÜak prom∞nnß, kterß obsahuje odkaz na tento objekt se nachßzφ na zßsobnφku. Tuto situaci lze pozorovat na obr. 3.

 

 

Obr. 3 û Ilustrace prßce hodnotov²ch a referenΦnφch typ∙

 

Pokud je o to po₧ßdanß, prom∞nnß poskytne adresu pam∞ti, na kterΘ je objekt ulo₧en. Jestli₧e je prom∞nnß zruÜena, zruÜφ se i odkaz na objekt, kter² byl v danΘ prom∞nnΘ umφst∞n. OvÜem pozor! Jestli₧e existujφ dalÜφ reference na dan² objekt, tento nenφ zlikvidovßn. Destrukce objektu (prost°ednictvφm Garbage Collection) nastßvß a₧ ve chvφli, kdy₧ na n∞j nejsou navßzßny ₧ßdnΘ dalÜφ odkazy.

 

 

Jßn Hanßk