Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Egy objektum szemléletű fejlesztői környezet

No description
by

Mónika Gál

on 7 November 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Egy objektum szemléletű fejlesztői környezet

Egy objektum szemléletű fejlesztői környezet - a .Net - néhány fontos tulajdonsága
Kivételkezelés
Assembly, Dll-ek használata
Szerializáció és perzisztencia
Verziókövetés
Kivételkezelés
Verziókövetés
Szerializáció és perzisztencia
A program futása során előálló hibák nagy részénél a .Net egy megfelelő típusú kivételt dob. Ha ezt a kivételt nem kezeljük, akkor a program futása leáll. Egy robusztus program minden olyan kivételt kezel, aminek keletkezésére egy adott programrészletnél számítani lehet. Az érzékeny kódrészt egy try blokkban helyezzük el. Ha a try blokkban kivétel keletkezik, akkor a catch részben elhelyezett kód hajtódik végre. A finally részben elhelyezett kódrész kivétel keletkezése nélkül és kivétel keletkezésekor is végrehajtódik.

Amikor a try blokkban lévő kód kivételt okoz, akkor valamelyik catch blokkban lévő kód fog lefutni, amennyiben az egyes catch blokkok megfelelő kivételtípusokat határoznak meg. Nem kötelező kivételtípust megadni, illetve megadhatjuk a kivételek általános típusát, mint az a következő példában látszik.
A catch utasítás egy e objektumot kap el, melynek ToString metódusával érthetjük el a kivétel tulajdonságait. Az e objektum message mezője egy rövidebb üzenetet jelenít meg. Előbbit a programozónak, utóbbit a felhasználónak célszerű megjeleníteni.
try
{ ... }
catch (...)
{ ... }
catch (...)
{ ... }
finally
{ ... }
try
{
szam1 = textBox1.Text;
szam2 = textBox2.Text;
szam3 = szam1 / szam2;
textBox3.Text = szam3;
catch (Exception e)
{
Messagebox.Show(e.ToString(...));
}
Kivételkezelés
Több catch blokk megadásával a kivételeket típusuk szerint szűrhetjük:
try
{
szam1 = TextBox1.Text
szam2 = TextBox2.Text
szam3 = szam1 / szam2
TextBox3.Text = szam3
}
catch (DivideByZeroException e)
{
MsgBox("Nullával való osztás történt")
}
catch (ArgumentOutOfRangeException e)
{
MsgBox("Nem megfelelő számérték.")
}
A finally részben található kód minden esetben lefut, akkor is, ha nem volt kivétel. Példa a finally használatára:
try
{
szam1 = TextBox1.Text;
szam2 = TextBox2.Text;
szam3 = szam1 / szam2;
}
catch (DivideByZeroException e)
{
MessageBox.Show("Nullával való osztás történt");
szam3=0;
}
finally
{
TextBox3.Text = szam3;
}
Kivételt mi is dobhatunk:
try
{
szam1 = TextBox1.Text;
szam2 = TextBox2.Text;
if (szam2<0) throw new Exception("Negatív szám a nevezőben.");
szam3 = szam1 / szam2;
TextBox3.Text = szam3;
}
catch (DivideByZeroException e)
{
MessageBox.Show("Nullával való osztás történt");
}
catch (ArgumentOutOfRangeException e)
{
MessageBox.Show("Nem megfelelő számérték.");
}
catch (Exception e)
{
MessageBox.Show(e.message)
}
Legalább egy catch-nek vagy egy finallynek lennie kell a try blokkban.

Az egyes kivételtípusoknak a Microsoft MSDN oldalán tudsz utánanézni:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemexceptionclasstopic.asp
Assembly
CLR (Common Language Runtime):
Egységes futási környezetet biztosít a .NET komponensek számára, függetlenül attól, hogy azokat milyen nyelven írták. Elvégzi a memóriakezelést, biztonságos futási környezetet biztosít, hozzáférést ad az operációs rendszer szolgáltatásaihoz. A CLR alatt futó kódot felügyelt kódnak nevezzük.
Köztes kód:
Ahhoz, hogy a programnyelv-függetlenség megvalósulhasson, a .NET alatt megírt különböző nyelvű programokból a fordítóprogram először létrehoz egy egységes nyelvű köztes kódot. (IL-kód) Elméletileg két különböző nyelvben létrehozott azonos szemantikájú szerkezetek, azonos IL-kódot eredményeznek. Az IL-kód gépi kódra fordítását a futásidejű (JIT) fordító végzi el. A létrehozott exe vagy dll állományban tehát tulajdonképpen az IL-kód szerepel kiegészítve egy gépi kóddal, amely a JIT fordítót hívja meg azért, hogy az lefordíthassa az IL-kódot gépi kódra. A futásidejű fordítás ugyan időt vesz igénybe, de számos előnnyel jár. Pl. lehetőség van arra, hogy a számítógép processzortípusának megfelelő kód jöjjön létre, kihasználva az adott processzor utasításkészletének előnyeit. (Megoldható az IL-kód kihagyása is, ehhez a Native Image Generator programot kell használni.)
CLR, köztes kód
A korábbi technológiánál, a COM-nál a dll-ek által megosztott logikai attribútumokat az ügyféloldalon manuálisan kellett kezelni. A program telepítésénél gondoskodni kellett a megfelelő dll-ek elhelyezéséről, új verziónál a régi dll-ek lecseréléséről, eltávolításáról. Amennyiben ez nem történt megfelelően, könnyen előfordulhatott, hogy az új verziójú alkalmazás egy régi dll-t próbált betölteni. A COM technológiánál a manuális verziószám-módosítás illetve a biztonsági attribútumok beállítása az alkalmazás által felhasznált összes dll-nél nehézségeket okozott. A biztonsági attribútumok teszik lehetővé, hogy az ügyféloldali alkalmazások megbizonyosodjanak az általuk felhasznált dll-ek megbízhatóságáról. Mindezeknek a nehézségeknek az ellenére a dll-használat továbbra is kívánatos, hiszen ez teszi lehetővé, hogy egy-egy komponenst csak akkor kelljen betölteni, amikor tényleg fel is akarjuk használni őket. Így optimalizálható a memóriafelhasználás.

A .Net assembly-k ezekre a problémákra kívánnak megoldással szolgálni. A .Net assembly egy önálló telepítési, verziókövetési és biztonsági egység, amely egy dll vagy exe attribútumait tárolja.
Egy assembly több névteret is tartalmazhat, de több assemblyben található komponensek is tartozhatnak ugyanahhoz a névtérhez. Egy dll felhasználásához elegendő az ügyfélben hivatkozni a megfelelő dll-re, majd a megfelelő névtér használatával ugyanúgy történik a komponensek használata, mintha az ügyfélprojektben lévő komponenseket használnánk. Az exe komponensekkel való együttműködéshez a .Net távelérést kell alkalmazni.

(
teljesen minősített típusnevek
: a névteret a típusmeghatározás részeként tartalmazó nevek.)

Láthatóság kezelése:

Az
internal
kulcsszóval jelölt komponensekhez csak assemblyn belül lehet hozzáférni, míg a public kulcsszóval jelöltekhez az assemblyn kívülről is. Az alapértelmezett hozzáférési szint a komponenseknél az internal. Amennyiben a komponenseken belül, csak egyes metódusok, tulajdonságok elérését szeretnénk az assemblyn belülre korlátozni, a public hozzáférési szint helyett a protected internal kulcsszavakkal kell ellátnunk.
Az ügyféloldali fordítóprogramnak érdemes tudni, hogy a felhasznált már lefordított komponensek milyen metódusokat, láthatóságokat használnak. A .Net ezt metaadatok bevezetésével oldotta meg. A metaadatok minden szükséges információt megadnak a dll-ről. Az elérhető interfészeket, komponenseket, azok metódusait, láthatóságait, paramétereit stb. Ezeket a metaadatokat a magas szintű fordítóprogram hozza létre a forrásfájlok alapján. A metaadatokat az IL-t tartalmazó fizikai fájlba, a dll-be vagy exe-be ágyazza. Ezeket a metaadatokat használja fel a reflektálás mechanizmusa, a távelérés, az IntelliSense. (Az assemblyk metaadatait, az ILDASM segédprogrammal nézhetjük meg. Várható elérési útvonala: C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools)
Az assemblyk manifestjei
A manifest tartalmazza
Az assembly nevét, verziószámát
Az ellenőrzéséhez szükséges biztonsági előírásokat.
A benne lévő fájlok nevét, hash-ét: amikor az assembly betöltésekor a .Net újragenerálja a hash-eket, akkor ha az itt tárolt hash különbözik az újragenerálttól, akkor nem tölti be az assemblyt, és kivételt dob. Így elkerülhető, hogy egy helytelenül lecserélt dll-t felhasználva programleállás következzen be.
Az assembly által hivatkozott minden assembly nevét, nyilvános kulcsát, verziószámát: ez garantálja, hogy futásidőben ezek az assemblyk lesznek betöltve, és csak a kompatibilis verzióik.
tartalmazhatja az assembly erős nevét: az erős név használatával biztosítható a komponens forgalmazója és felhasználója közti bizalmi viszony, mert erős névvel csak a forgalmazó láthatja el az assemblyt.
A manifestet is a magas szintű fordítóprogram hozza létre. A .Net a hivatkozott assemblykről a manifest segítségével szerez információkat. Ez biztosítja a verziókompatibilitást, és hogy az assembly pontosan azokkal a megbízható assemblykkel kerüljön kapcsolatba, akikkel szeretne.
A manifest módosítása az assembly információs fájlban történik, amelyet a .Net automatikusan generál.
Assembly típus:
A System.Reflection névtérben található meg az Assembly osztály, amelynek segítségével részletes információkhoz juthatunk az assemblyről. Pl. lekérdezhetők egy assembly által hivatkozott assemblyk, az assembly neve, moduljai stb.
Bináris kompatibilitás:
A bináris komponensek felhasználásának követelménye a bináris kompatibilitás, amely mindkét felet egy szerződés – tipikus esetben egy interfész betartására kötelezi. Amíg a kiszolgáló objektum megfelel ennek az interfésznek, addig az ügyfelet nem befolyásolják a kiszolgáló oldalon történő változások.
A
COM
a bináris kompatibilitást interfészmutatókkal és virtuális táblákkal biztosította. Az ügyfél interfészmutatói egy virtuális táblára mutattak, amelyek egyes sorai a függvénymutatók táblájának soraira hivatkoztak. A függvénymutatók mutattak a megfelelő interfészmetódus kódjára. Az ügyfelek által használt interfészmutatókat a fordítóprogram offszetekkel fordítja le a virtuális tábla első sorához képest. A virtuális tábla szerkezetét tehát nem lehet megváltoztatni, ebből ered a COM első szabálya: „Nem változtatható meg egy közzétett interfész.” Az interfész megváltoztatásakor újra kell fordítani az összes ügyfelet, ahhoz, hogy a bináris kompatibilitás újra biztosított legyen.
A
.Net
a bináris kompatibilitást a metaadatok segítségével valósítja meg. Az IL-kód csak metódusok hívását vagy objektummezők elérését tartalmazza, és nem offszeteket, hiszen a végleges bináris struktúra csak futás közben születik meg a JIT fordító által. A .Net bináris kompatibilitása ezért nem korlátozódik csak interfész alapú programozásra, a metódusok sorrendje felcserélhető, az ügyfél által nem használt metódusok eltávolíthatók, új metódusok létrehozhatók. Ezek a COM-ban tiltott tevékenységek voltak, hiszen ellentmondtak az első szabálynak.
A dll fájlok célja, hogy egy - egy adott modult számos alkalmazás használhasson. Komoly problémák merülhetnek azonban fel, ha egy alkalmazás olyan dll fájl telepít fel a rendszerre, amelynek egy korábbi változata már jelen volt a számítógépen, és egy másik alkalmazás használja azt. Az új változat ugyanis szükséges az alkalmazás futásához, a már feltelepített másik programban azonban hibát okozhat a módosított dll. A problémát az is fokozza, hogy a Windows, illetve az alkalmazások nem tudják megállapítani a dll könyvtárak verziószámát.

A verziókövetés azt a célt szolgálja, hogy az ügyfelek képesek legyenek mindig a kiszolgáló komponens kompatibilis verziójával együttműködni. A .Net egyik legfontosabb célja a komponensek telepítésének és verziókövetésének egyszerűsítése volt.
Privát komponens
: mindig kizárólag az őket használó alkalmazások számára hozzáférhető helyen találhatók meg, az ügyfelek létrehozzák másolatukat a saját elérésű könyvtárukba. Ezeket kevésbé érintik a verziókövetéssel járó problémák.
Megosztott komponens:
Bizonyos helyzetekben az is fontos, hogy az egyes komponensek különböző verzióit biztosítsuk a különböző ügyfelek számára. A megosztott komponensek globálisan ismert helyen találhatók, több alkalmazás használja őket. Ezek verziókövetése nehezebb, de mégis szükséges, hogy a komponenseket több alkalmazás között megosszuk. A megosztott assemblyket, az ún. globális assembly gyorsítótárba (GAC) kell elhelyezni, amely ugyanannak az assemblynek több verzióját is egyszerre képes kezelni. Így ha a régebbi verzió jelen van, akkor az új verziónak nem kell visszafelé kompatibilisnek lennie.
Verziószám
Minden assemblyhez tartozik egy verziószám attribútum, amely a benne található összes komponensre vonatkozik. Ezt az AssemblyInfo fájl tartalmazza. Szerkezete a következő:
[assembly: AssemblyVersion(„1.2.3.4”)]
A verziószám elemei:
1: főverziószám
2: alverziószám
3: Építési szám
4: Revíziószám
Assembly-k ugyanazzal a névvel de különböző főverziószámmal nem felcserélhetők. A különböző főverziószám nagymértékű változást, termék újraírást jelez, ahol nincs visszafelé kombatibilitás.
Ha a főverziószám ugyanaz, de az alverziószám különbözik, az a visszafelé kombatibilitás szándékát jelzi.
Különböző építési szám ugyanazon forrásállomány újrafordítását jelezheti, a processzor, vagy a platform különböző lehet az előző verzióhoz képest.Az építési szám növelésével nagyobb, a revíziószám emelésével apróbb változtatásokat jelzünk.
A revíziószám megváltozása teljes felcserélhetőséget jelent, általában csak valamilyen biztonsági rés befoltozását jelzi.
Az építési és a revíziószám automatikusan is generáltatható, ha a helyükre az attribútumbeállításnál * kerül. Ekkor az építési szám a 2001. január 1. óta eltelt napok számát adja meg, a revíziószám pedig az éjfél óta eltelt másodpercek felét. Ez az alapbeállítás a .Net-ben.
[assembly: AssemblyVersion(„1.2.*”)]
Ha csak az első két számot szeretnénk használni, akkor az utolsó kettőt egyszerűen ne adjuk meg, ekkor azok értéke 0 lesz.
[assembly: AssemblyVersion(„1.2”)]
Ha az építési számokat mi szeretnénk generálni, akkor csak a revíziószámhoz írjunk *-ot.
[assembly: AssemblyVersion(„1.2.3.*”)]
A verziószám a kiszolgáló assembly manifestjében található. Amikor egy ügyfél hivatkozik egy kiszolgálóra, akkor saját manifestjében annak a kiszolgálónak a nevét és verziószámát rögzíti, amelyre fordításkor hivatkozott.
.assembly extern kiszolgalo
{.ver 1:2:3:4}
Erős nevű megosztott assemblyk
Mivel a privát assemblyk használata egyszerűbb, ezért két esetben érdemes megosztott assemblyt használni:
Ha egy adott assembly több verzióját szeretnénk párhuzamosan használni
Az assemblyt több ügyfél között szeretnénk megosztani.
A GAC több forgalmazótól származó assemblyket tárolhat, amelyek közt így lehetnek azonos nevűek is. A .NET-ben a megosztott assemblyknek ezért rendelkezniük kell egy egyedi ún. erős névvel, amely azonosítja az eredeti tartalmukat és a létrehozójukat. Az assembly erős nevének beállításához először létre kell hoznunk egy fájlt, amelyben a titkosítási kulcspárok lesznek: egy nyilvános és egy titkos kulcs. Fordításkor a fordítóprogram a titkos kulccsal kódolja az assembly manifestjét. Ez a titkosított hash az assembly egyedi digitális aláírása, amely igazolja a származást és a tartalmat. A digitális aláírást és a nyilvános kulcsot a manifest tartalmazza.
Egy erős nevű assemblyre hivatkozó ügyfél a manifestjében rögzíti a kiszolgálóassembly nyilvános kulcsát és verziószámát. Ilyenkor a .Net először a GAC-ben keresi a megfelelő assemblyt a barátságos név alapján. A megtaláltak közül azt választja ki, amely erős neve alapján is megfelel. Az erős név biztosíték arra, hogy más nem képes ugyanilyen digitális aláírással ellátott assembly létrehozására. (Kivéve, ha megszerzi a kulcspárt tartalmazó fájlt…)
Erős nevű privát assemblyk
Ha egy privát assemblynek nincs erős neve (vagyis csak barátságos neve van), akkor a .Net csak a verziószámát rögzíti a rá hivatkozó ügyfél manifestjében. Ennek ellenére csak barátságos névvel rendelkező assemblyk esetén nem ragaszkodik ahhoz, hogy csak az adott verziószámú assemblyt használja fel. Bármilyen verziójú assemblyt betölt ebben az esetben, tehát a kompatibilitást a fejlesztőkre bízzák.
Ha a privát assemblynek van erős neve, akkor csak a manifestben szereplő verziószámú assemblyt fogja betölteni a .Net.
A lényeg tehát:
A csak barátságos névvel rendelkező privát assemblyknek kompatibilisnek kell lenniük, de az erős nevű privát assemblyknek nem feltétlenül, hiszen a GAC tartalmazhat megfelelő verziót
Az ún assemblyfeloldó az erős nevű assemblyket először a GAC-ben keresi, és ha ott nem talál megfelelő verziószámút, akkor az alkalmazás könyvtárában próbálkozik.
Ha a GAC nem tartalmaz megfelelő erős névvel rendelkező assemblyt, de van privát assembly, amely rendelkezik erős névvel, viszont a verziószáma nem egyezik, akkor a .Net kivételt dob, és nem tölti be az assemblyt.
Erős nevű assemblyk csak erős nevű assemblykre hivatkozhatnak. Ennek az az oka, hogy az erős név az assembly megbízhatóságát jelzi. Márpedig ez a megbízhatóság elveszik, ha az erős nevű assembly barátságos nevűre hivatkozik.
Megosztott assemblyk telepítése a GAC-be

A GAC tulajdonképpen a Windows mappa Assembly almappája. Ide kell az erős névvel ellátott assemblyket bemásolni.

A másik lehetőség, hogy a GacUtil nevű parancssori segédprogramot használjuk.

A harmadik módszer a .Net Configuration tool alkalmazása: (C:\WINDOWS\Microsoft.NET\Framework\verzioszam\mscorcfg.msc). Itt megtekinthetők az assemblyk különböző tulajdonságai (verziószám, nyilvános kulcs kivonata). -> a 4.0-s .NET már nem tartalmazza ezt a fájlt

A .Net létrehozza az assembly helyi másolatát, de ha ezt el szeretnénk kerülni, akkor a References-ek között a megosztott assembly Local copy tulajdonságát, állítsuk false-ra.

Bizonyos helyzetekben szükség lehet arra, hogy a program futása során ellenőrizzük, hogy a betöltött assembly megosztott-e. Ilyenkor az éppen futó assembly GlobalAssemblyCache metódusát kell meghívni. Ha ennek visszatérési értéke true, akkor az assembly globális.
Alkalmazásainkban gyakori követelmény, hogy egyes részeinek állapotára emlékezzen az alkalmazás leállítása és újraindítása után. Ehhez a megfelelő objektumok adatmezőinek értékeit a háttértárolóra kell mentenünk, majd indításkor betöltenünk. A szerializáció és deszerizalizáció mechanizmusa ehhez a művelethez nyújt támogatást.

A cél az, hogy ezeknek a műveleteknek a megvalósításával a fejlesztőnek ne kelljen túl sok időt töltenie. A különböző forrásokból származó komponenseket egyetlen ún. perzisztens fájlban kell tárolni egy alkalmazás esetében.
Automatikus szerizalizáció és deszerializáció
Az automatikus szerializációt a .Net a metaadatok segítéségével valósítja meg, így akár private mezők értékeit is kiolvashatja.
A szerializációra használt kód teljesen általános, bármely osztálytípuson elvégezhető.
Az objektum állapota egy adatfolyamba kerül. (System.IO névtér Stream osztályának leszármazottjainak valamelyikébe.)
A szerializáció objektumok mezőin végezhető el, ezért a statikus tagok nem szerializálhatók.
Alapértelmezetten egy felhasználó által definiált típus (osztály vagy struktúra) nem szerializálható. .Net az osztály fejlesztőjére bízza annak eldöntését, hogy az osztály állapota szerializálható legyen-e. Ahhoz, hogy azzá tegyük, a Serializable attribútummal kell ellátnunk.
Ha egy osztályt ellátunk a Serializable attribútummal, akkor az összes olyan adatmezője szerializálásra kerül, amely szintén szerializálható -> Ha az osztálynak olyan adatmezői vannak, amelynek típusa szintén egy osztály, akkor automatikusan szerializásra kerülnek ennek az osztálynak az állapotaként az ő adatmezői is.
A szerializáció mechanizmusa rekurzív bejárási algoritmust használ, megjelöli a már bejárt elemeket. Elég okos ahhoz, hogy akár kétirányú láncolt listák szerializálását is elvégezze.
A .Net nem szerializálható tagok esetén SerializationException kivételt dob. Olyan típusok esetén történhet meg ez, amelyek speciális inicializást kívánnak meg. A probléma elkerüléséhez az adatmezőt a NonSerialized attribútummal kell megjelölnünk.
A NonSerialized attribútummal megjelölt adatmezőket a .Net figyelmen kívül hagyja a szerializációkor. Deszerializáláskor a nem szerializálható mezők értéke a típus alapértéke lesz, objektumok esetén null. Tehát ezeknek az adatmezőknek az inicializálásáról a továbbiakban a fejlesztőknek kell gondoskodni.
A deszerializáció elvégzése után a .Net meghívja az IDeserializationCallback OnDeserialization metódusát, amely a System.Runtime.Serialization névtérben található. A nem szerializálható adatmezőket itt célszerű inicializálni.
Írásvédett tagok inicializálása csak egyéni szerializáció útján lehetséges.
public class EgyOsztaly
{…}
[Serializable]
public class EgyMasikOsztaly
{
[NonSerialized]
EgyOsztaly o;

}
A formázó egy objektum, amely megvalósítja az IFormatter interfészt. (System.Runtime.Serizalizaton névtér) Rendelkezik egy Serialize(Stream adatfolyam, object graf) metódussal, amellyel a szerializációt valósítjuk meg, és egy Deserialize(Stream adatfolyam) metódussal amellyel pedig a deszerializációt.
A formázóknak két típusa van:
Bináris: az objektum állapotát bináris kódok formájában tömöríti (BinaryFormatter osztály – System.Runtime.Serialization.Formatters.Binary névtér)
SOAP (Simple Object Access Protocol): az objektum állapotát xml formátumban menti. Ez a bináris formázónál természetesen jóval lassabban működik és nagyobb adatmennyiséget is jelent. Előnye a platformfüggetlenség. (SoapFormatter osztály – System.Runtime.Serialization.Formatters.SoapFormatter névtér)

Bináris szerializáció és deszerializáció

A Soap formázót ugyanilyen módon kell alkalmazni, csak a BinaryFormatter helyett a SoapFormatter osztályt kell használni.
Megtehetjük, hogy egy adatfolyamba több objektum állapotát is szerializáljuk. Ekkor a deszerializáció ugyanabban a sorrendben kell elvégezni.
Szerializációformázók
EgyOsztaly o=new EgyOsztaly;

//Szerializáció
Stream adatfolyam=new FileStream(„szer.bin”,FileMode.Create, FileAccess.Write);
IFormatter f=new BinaryFormatter();
f.Serialize(adatfolyam, o);
adatfolyam.Close();
//Deszerializáció
EgyOsztaly o; //nem használjuk a new utasítást!
Stream adatfolyam=new FileStream(„szer.bin”,FileMode.Open, FileAccess.Read);
IFormatter f=new BinaryFormatter();
o=(EgyOsztaly)f.Deserialize(adatfolyam); /*a Deserialize által visszaadott általános object típust castoljuk a megfelelő osztály típusára.*/
adatfolyam.Close();
Feladat
Készítsünk egy alkalmazást, amely egy listadobozt tartalmazó alkalmazás utolsó bezárása előtti állapotát jeleníti meg az alkalmazás következő elindításakor.
A listadoboz nem szerializálható típus, ezért hozzunk létre egy osztályt, amely egy listadoboz értékeit tárolja egy tömbben, lehetővé teszi a tömb adatainak lekérdezését és szerializációját.
Hozzunk létre egy felhasználói felületet, amelyen egy listadoboz egy szövegdoboz és egy Új elem illetve egy Törlés feliratú gomb szerepel.
Az Új elem gombbal a szövegdobozban szereplő stringet adhatjuk hozzá a szövegdobozhoz.
A Törlés feliratúval a listadoboz aktuális elemét törölhetjük.
Az alkalmazás bezárásakor mentsük el a listadobozban szereplő értékeket az általunk létrehozott osztály egy példányába, majd szerializáció segítségével perzisztáljuk az objektum állapotát.
Az alkalmazás indításakor deszerializáljuk az objektum állapotát, és jelenítsük meg a listadobozban az objektumban szereplő tömbértékeket.

A SzerLB osztály mezői:
M_elemek stringtömbbe kerülnek a listadoboz értékei, ez a tömb a konstruktorban kerül feltöltésre
GetElemek metódust egy csak olvasható propertyként hozzuk létre az m_elemek tömb értékeinek visszaadására.
A szerializáció a form bezárásakor, a deszerializáció a form betöltődésekor hajtódjon végre.
Forrás: Juval Löwy: .NET komponensek programozása, Kossuth Kiadó, 2004
Full transcript