SzoftTechVizsga100525 - Laptörténet

Nagy Marcell: autoedit v2: fájlhivatkozások egységesítése, az új közvetlenül az adott fájlra mutat

2017-07-12T14:23:04Z

autoedit v2: fájlhivatkozások egységesítése, az új közvetlenül az adott fájlra mutat

← Régebbi változat		A lap 2017. július 12., 16:23-kori változata
80. sor:		80. sor:

	==5. Rajzoljon fel példát egy-több (1:n), több-több (m:n) relációkra (osztálydiagram), és írja fel, milyen táblákba képezné le őket! (12p)==		==5. Rajzoljon fel példát egy-több (1:n), több-több (m:n) relációkra (osztálydiagram), és írja fel, milyen táblákba képezné le őket! (12p)==
	[[~~Fájl~~:sznikak_vizsga_20100525_relacios_diag.png]]		[[File:sznikak_vizsga_20100525_relacios_diag.png]]

	==6. Tervezési minták==		==6. Tervezési minták==
97. sor:		97. sor:
	'''Megoldás:''' adapter minta használata. Felveszünk egy ''Shape'' -ből származó ''TextShape'' osztályt, melynek metódusai megfelelnek az elvártnak (nyilván, hiszen a ''Shape'' -t implementáljuk). A ''TextShape'' osztály tartalmaz egy referenciát egy ''TextView'' objektumra, és a megfelelő metódushívásokat ezen keresztül delegálja a ''TextView'' osztálynak.		'''Megoldás:''' adapter minta használata. Felveszünk egy ''Shape'' -ből származó ''TextShape'' osztályt, melynek metódusai megfelelnek az elvártnak (nyilván, hiszen a ''Shape'' -t implementáljuk). A ''TextShape'' osztály tartalmaz egy referenciát egy ''TextView'' objektumra, és a megfelelő metódushívásokat ezen keresztül delegálja a ''TextView'' osztálynak.

	[[~~Fájl~~:sznikak_vizsga_20100525_adapter_design_pattern.png]]		[[File:sznikak_vizsga_20100525_adapter_design_pattern.png]]

	Az ábrán szereplő osztályok és szerepük:		Az ábrán szereplő osztályok és szerepük:
108. sor:		108. sor:
	Az architektúra 2 szereplője: Document és View. A Document feladata az adatok tárolása és menedzselése. Olyan osztályok mely, az adatokat a tagváltozóikban tárolják, és olyan tagfüggvényekkel rendelkeznek, melyek kezelik ezeket az adatokat és elérhetővé teszik más osztályok számára. A View feladat az adatok megjelenítése, a Document adatai alapján. A felhasználói interakciók során általában a nézet a dokumentum tartalmát módosítja; általában egy tab-fülként vagy egy ablakként jelenik meg. Elve: az adat megjelenítésért és annak kezeléséért felelős kód szétválasztása 2 részre.		Az architektúra 2 szereplője: Document és View. A Document feladata az adatok tárolása és menedzselése. Olyan osztályok mely, az adatokat a tagváltozóikban tárolják, és olyan tagfüggvényekkel rendelkeznek, melyek kezelik ezeket az adatokat és elérhetővé teszik más osztályok számára. A View feladat az adatok megjelenítése, a Document adatai alapján. A felhasználói interakciók során általában a nézet a dokumentum tartalmát módosítja; általában egy tab-fülként vagy egy ablakként jelenik meg. Elve: az adat megjelenítésért és annak kezeléséért felelős kód szétválasztása 2 részre.
	<p align="center">		<p align="center">
	[[~~Fájl~~:sznikak_vizsga_20100525_d-v.png]]		[[File:sznikak_vizsga_20100525_d-v.png]]
	</p>		</p>
	A szekvencia diagram úgy néz ki, hogy a Document példány kap egy UpdateAllViews() metódus hívást, mire az sorra meghívja View példányok Update() metódusát. Ha felhasználói interakció történik, akkor a View is tud jelezni a Document felé (setData()) /?/.		A szekvencia diagram úgy néz ki, hogy a Document példány kap egy UpdateAllViews() metódus hívást, mire az sorra meghívja View példányok Update() metódusát. Ha felhasználói interakció történik, akkor a View is tud jelezni a Document felé (setData()) /?/.
116. sor:		116. sor:
	Alapigazság: de drótozzuk be a GUI-ba az alkalmazás logikát. Szereplők: Model (alkalmazás logika), View(megjelenítés) és Controller(interakció - kommunikáció a felhasználóval).		Alapigazság: de drótozzuk be a GUI-ba az alkalmazás logikát. Szereplők: Model (alkalmazás logika), View(megjelenítés) és Controller(interakció - kommunikáció a felhasználóval).
	<p align="center">		<p align="center">
	[[~~Fájl~~:sznikak_vizsga_20100525_mvc.png]]		[[File:sznikak_vizsga_20100525_mvc.png]]
	</p>		</p>

Szikszayl, 2013. október 5., 13:52-n

2013-10-05T13:52:41Z

← Régebbi változat		A lap 2013. október 5., 15:52-kori változata
141. sor:		141. sor:
	* aspx fájlból HTML kódok segítségével testre-szabható a megjelenésük		* aspx fájlból HTML kódok segítségével testre-szabható a megjelenésük

	~~Műdköés~~:		Működés:
	* első lekéréskor lefordul az aspx és a code-behind fájl egy temp könyvtárba DLL formájában		* első lekéréskor lefordul az aspx és a code-behind fájl egy temp könyvtárba DLL formájában
	* a lefordított kód feldolgozza a bejövő kérést és előállítja a választ		* a lefordított kód feldolgozza a bejövő kérést és előállítja a választ
149. sor:		149. sor:

	-- [[OlahPeter\|pepe]] - 2011.05.30.		-- [[OlahPeter\|pepe]] - 2011.05.30.


	[[Category:Infoalap]]		[[Category:Infoalap]]

Ferrero: /* 7. Ismertesse az MVC (Model-View-Control) vagy a Dokumentum/Nézet (Document-View) architektúrát. Ennek keretében rajzolja fel a minta osztály és szekvenciadiagrammját. Adja meg az egyes osztályok szerepét! (14p) */

2013-02-06T09:19:38Z

7. Ismertesse az MVC (Model-View-Control) vagy a Dokumentum/Nézet (Document-View) architektúrát. Ennek keretében rajzolja fel a minta osztály és szekvenciadiagrammját. Adja meg az egyes osztályok szerepét! (14p)

← Régebbi változat		A lap 2013. február 6., 11:19-kori változata
108. sor:		108. sor:
	Az architektúra 2 szereplője: Document és View. A Document feladata az adatok tárolása és menedzselése. Olyan osztályok mely, az adatokat a tagváltozóikban tárolják, és olyan tagfüggvényekkel rendelkeznek, melyek kezelik ezeket az adatokat és elérhetővé teszik más osztályok számára. A View feladat az adatok megjelenítése, a Document adatai alapján. A felhasználói interakciók során általában a nézet a dokumentum tartalmát módosítja; általában egy tab-fülként vagy egy ablakként jelenik meg. Elve: az adat megjelenítésért és annak kezeléséért felelős kód szétválasztása 2 részre.		Az architektúra 2 szereplője: Document és View. A Document feladata az adatok tárolása és menedzselése. Olyan osztályok mely, az adatokat a tagváltozóikban tárolják, és olyan tagfüggvényekkel rendelkeznek, melyek kezelik ezeket az adatokat és elérhetővé teszik más osztályok számára. A View feladat az adatok megjelenítése, a Document adatai alapján. A felhasználói interakciók során általában a nézet a dokumentum tartalmát módosítja; általában egy tab-fülként vagy egy ablakként jelenik meg. Elve: az adat megjelenítésért és annak kezeléséért felelős kód szétválasztása 2 részre.
	<p align="center">		<p align="center">
	~~https~~:~~//wiki.sch.bme.hu/pub/Sandbox/OlahPeterSandbox/d~~-v.png		[[Fájl:sznikak_vizsga_20100525_d-v.png]]
	</p>		</p>
	A szekvencia diagram úgy néz ki, hogy a Document példány kap egy UpdateAllViews() metódus hívást, mire az sorra meghívja View példányok Update() metódusát. Ha felhasználói interakció történik, akkor a View is tud jelezni a Document felé (setData()) /?/.		A szekvencia diagram úgy néz ki, hogy a Document példány kap egy UpdateAllViews() metódus hívást, mire az sorra meghívja View példányok Update() metódusát. Ha felhasználói interakció történik, akkor a View is tud jelezni a Document felé (setData()) /?/.
116. sor:		116. sor:
	Alapigazság: de drótozzuk be a GUI-ba az alkalmazás logikát. Szereplők: Model (alkalmazás logika), View(megjelenítés) és Controller(interakció - kommunikáció a felhasználóval).		Alapigazság: de drótozzuk be a GUI-ba az alkalmazás logikát. Szereplők: Model (alkalmazás logika), View(megjelenítés) és Controller(interakció - kommunikáció a felhasználóval).
	<p align="center">		<p align="center">
	~~https~~:~~//wiki.sch.bme.hu/pub/Sandbox/OlahPeterSandbox/mvc~~.png		[[Fájl:sznikak_vizsga_20100525_mvc.png]]
	</p>		</p>

129. sor:		129. sor:
	* A modell értesíti a változásról a view-(ka)t		* A modell értesíti a változásról a view-(ka)t
	* A view/view-ek lekérdezi(k) a modell állapotát és az alapján frissül(nek)		* A view/view-ek lekérdezi(k) a modell állapotát és az alapján frissül(nek)



	==8. ASP.NET kiszolgáló oldali vezérlők (jellemzők, szerepük, működésük, példakód) (14p)==		==8. ASP.NET kiszolgáló oldali vezérlők (jellemzők, szerepük, működésük, példakód) (14p)==

Ferrero: /* 5. Rajzoljon fel példát egy-több (1:n), több-több (m:n) relációkra (osztálydiagram), és írja fel, milyen táblákba képezné le őket! (12p) */

2013-02-06T09:18:39Z

5. Rajzoljon fel példát egy-több (1:n), több-több (m:n) relációkra (osztálydiagram), és írja fel, milyen táblákba képezné le őket! (12p)

← Régebbi változat		A lap 2013. február 6., 11:18-kori változata
80. sor:		80. sor:

	==5. Rajzoljon fel példát egy-több (1:n), több-több (m:n) relációkra (osztálydiagram), és írja fel, milyen táblákba képezné le őket! (12p)==		==5. Rajzoljon fel példát egy-több (1:n), több-több (m:n) relációkra (osztálydiagram), és írja fel, milyen táblákba képezné le őket! (12p)==
	~~https~~:~~//wiki.sch.bme.hu/pub/Sandbox/OlahPeterSandbox/relacios_diag~~.png		[[Fájl:sznikak_vizsga_20100525_relacios_diag.png]]

	==6. Tervezési minták==		==6. Tervezési minták==

Ferrero: /* 6. Tervezési minták */

2013-02-06T09:17:53Z

6. Tervezési minták

← Régebbi változat		A lap 2013. február 6., 11:17-kori változata
97. sor:		97. sor:
	'''Megoldás:''' adapter minta használata. Felveszünk egy ''Shape'' -ből származó ''TextShape'' osztályt, melynek metódusai megfelelnek az elvártnak (nyilván, hiszen a ''Shape'' -t implementáljuk). A ''TextShape'' osztály tartalmaz egy referenciát egy ''TextView'' objektumra, és a megfelelő metódushívásokat ezen keresztül delegálja a ''TextView'' osztálynak.		'''Megoldás:''' adapter minta használata. Felveszünk egy ''Shape'' -ből származó ''TextShape'' osztályt, melynek metódusai megfelelnek az elvártnak (nyilván, hiszen a ''Shape'' -t implementáljuk). A ''TextShape'' osztály tartalmaz egy referenciát egy ''TextView'' objektumra, és a megfelelő metódushívásokat ezen keresztül delegálja a ''TextView'' osztálynak.

	~~https~~:~~//wiki.sch.bme.hu/pub/Sandbox/OlahPeterSandbox/adapter_design_pattern~~.png		[[Fájl:sznikak_vizsga_20100525_adapter_design_pattern.png]]

	Az ábrán szereplő osztályok és szerepük:		Az ábrán szereplő osztályok és szerepük:

Ferrero, 2013. február 6., 09:16-n

2013-02-06T09:16:49Z

← Régebbi változat		A lap 2013. február 6., 11:16-kori változata
1. sor:		1. sor:
	~~{{GlobalTemplate\|Infoalap\|SzoftTechVizsga100525}}~~

	==1. Definiálja és jellemezze a .NET szerelvény (assembly) fogalmát (szerepe, típusai, azonosítása) (12p) <br>==		==1. Definiálja és jellemezze a .NET szerelvény (assembly) fogalmát (szerepe, típusai, azonosítása) (12p) <br>==
	Funkciók fizikai egysége. Általában egy .dll vagy egy .exe fájl (de lehet több is). Minden alkalmazás szerelvényekből épül fel. Az egymás-melletti futás alapegysége (ugyanabból a szerelvényből több verzió is futhat).		Funkciók fizikai egysége. Általában egy .dll vagy egy .exe fájl (de lehet több is). Minden alkalmazás szerelvényekből épül fel. Az egymás-melletti futás alapegysége (ugyanabból a szerelvényből több verzió is futhat).

Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoalap|SzoftTechVizsga100525}} ==1. Definiálja és jellemezze a .NET szerelvény (assembly) fogalmát (szerepe, típusai, azonosítása) (12p)
…”

2012-10-21T20:22:44Z

Új oldal, tartalma: „{{GlobalTemplate|Infoalap|SzoftTechVizsga100525}} ==1. Definiálja és jellemezze a .NET szerelvény (assembly) fogalmát (szerepe, típusai, azonosítása) (12p) …”

Új lap

{{GlobalTemplate|Infoalap|SzoftTechVizsga100525}}

==1. Definiálja és jellemezze a .NET szerelvény (assembly) fogalmát (szerepe, típusai, azonosítása) (12p) ==
Funkciók fizikai egysége. Általában egy .dll vagy egy .exe fájl (de lehet több is). Minden alkalmazás szerelvényekből épül fel. Az egymás-melletti futás alapegysége (ugyanabból a szerelvényből több verzió is futhat).

'''Magában foglal:'''
* metaadatokat a szerelvényről (manifest)
* metaadatokat a .NET osztályokról
* erőforrásokat

'''Típusai:'''
* privát - egyetlen alkalmazás használja, neve azonosítja, az alkalmazás mappáiban keresi
* azonosított (strong named)
** erős név teszi egyedivé
** csak azonosított szerelvényekre hivatkozhat
** több alkalmazás használhatja
** DLL Hell problémára megoldás
** integritás védelmet nyújt (digitálisan aláírható szerelvények)

'''Erős név:''' név + fejlesztői cég nyilvános kulcsa + verziószám [+ nyelv és kultúra]
==2. Ismertesse a C# nyelv attribútum (Attribute) fogalmát! Mutasson kódrészletet az alkalmazására (csak az alkalmazásra, lekérdezésre nem)! (12p)==
Az attribútumok segítségével deklaratív jelleggel metaadatokat közölhetünk a kód bizonyos részeire vonatkozóan. Az attribútum is tulajdonképpen egy osztály, amit hozzákötünk a program egy megadott eleméhez (típushoz, osztályhoz, metódushoz...). Az attribútumok a program futása közben is kiolvashatók, általában a CLR számára szeretnénk információkat közölni a segítségükkel.

Alkalmazási példa:
<pre>
[Serializable] // jelezzük hogy az osztály sorosítható (ez egy attribútum)
class User
{
string name;

[NonSerialized] // jelezzük, hogy ezt a mezőt nem szükséges sorosítani
string password;

...
}
</pre>
(szerintem ennyi elég példának)

==3. Eseményvezérelt programozás és grafikus megjelenítés==
* '''a) Ismertesse röviden az érvénytelen terület fogalmát! Hogyan kapcsolódik ez a Paint eseményhez? (7p)''' 
* '''b) Írjon olyan C# nyelvű alkalmazásrészletet, ami a (20, 20) koordinátában megjeleníti, hogy a legutóbbi egérkattintás óta hány másodperc telt el! (Lehetett használni egy TimeDiff nevű függvényt, aminek 2 db DateTime a bemenete és visszaadja szöveges formában, hogy hány mp telt el. DateTime.Now-val kellett lekérni a jelenlegi időt). A megjelenítés GDI-re épüljön (nem használhatja a Label, Textbox, stb. vezérlőket). Csak a megoldáshoz sorosan kapcsolódó kódrészeket adja meg! (8p)''' 

a) Érvénytelen terület: korábban takarásban lévő, láthatóvá vált ablakrészek. Mivel a memória korlátok miatt, az OS nem jegyzi meg az ablakok rajzolatát, így az érvénytelen területeket újra kell rajzolni. Amikor egy érvénytelen terület keletkezik, akkor WM_PAINT üzenetet kap az ablak (natív Win32), ami a Paint eseménynek felel meg.

b) Ha nincsenek megadva a fent említett függvények, akkor a kódrészlet így néz ki:
<pre>

DateTime lastClick;
String strDeltaTime;
private void Form1_Load(object sender, EventArgs e)
{
lastClick = DateTime.Now;
strDeltaTime = "0";
}

private void Form1_MouseClick(object sender, MouseEventArgs e)
{

TimeSpan deltaTime = DateTime.Now.Subtract(lastClick);
lastClick = DateTime.Now;
strDeltaTime = deltaTime.Seconds.ToString();
Invalidate(); // érvényteleníteni kell az ablak területet, hogy az új érték látszódjon (lényegében ezzel "hívjuk" meg az OnPaint metódust)
}

protected override void OnPaint(PaintEventArgs e) {
e.Graphics.DrawString(strDeltaTime, this.Font, new SolidBrush(Color.Black), 20, 20);
base.OnPaint(e);
}
</pre>
==4. Szálkezelés==
* '''a) Hasonlítsa össze a Mutex és a C# Lock zárolási konstrukciókat! (2p)''' 
* '''b) Meg kell-e valósítani a kölcsönös kizárást az alábbi esetekben? (Indokolja!)''' 
** '''i) lokális változóhoz való hozzáférés, (2p)''' (nem) 
** '''ii) a globális heap-en (?) allokált memóriaterülethez való hozzáférés (2p)''' (igen) 
* '''c) Jellemezze egy mondatban a ReaderWriterLock osztályt. (2p)''' 

a) '''Lock:''' biztosítja, hogy egy adott erőforráshoz/kódrészlethez egy időben csak egy szál férhet hozzá. '''Mutex:''' hasonló mint, a lock, viszont folyamatok között is működik. (pl. alkalmazásból csak egy példány futhat)

b) Szerintem: i) a lokális változók nem a szálak közötti kölcsönösen használt memória területen jönnek (hanem a stack-en /?/), tehát nem kell. ii) a globális változók a heap-en jönnek létre, így azok a szálak között közösen elérhető erőforrás, így meg kell valósítani a kizárást.

c) Olyan kölcsönös kizárási megoldás, mely az adott erőforráshoz olvasási hozzáférést egyszerre több olvasónak is engedélyez, de íróból csak egyet. (az író kizárja az olvasókat is)

==5. Rajzoljon fel példát egy-több (1:n), több-több (m:n) relációkra (osztálydiagram), és írja fel, milyen táblákba képezné le őket! (12p)==
https://wiki.sch.bme.hu/pub/Sandbox/OlahPeterSandbox/relacios_diag.png

==6. Tervezési minták==
* '''a) Adja meg röviden, hogy miben és hogyan segítenek a tervezési minták a tervezés során! (3p)''' 
* '''b) Jellemezze a "Adapter" tervezési mintát! Mire ad megoldást a "Adapter" tervezési minta? Mutassa be konkrétan vagy egy példán keresztül a minta működését (vagy a class adaptert vagy az object adaptert, mindkettőt ne)! Ezen felül rajzolja fel a minta osztálydiagramját, valamint adja meg a mintában szereplő osztályok szerepét! (10p)'''

a) A tervezési minta leír egy gyakran előforduló problémát, annak környezetét és a megoldás magját, amit alkalmazva számos gyakorlati eset megoldható. A tervezési minták a fejlesztés tervezés fázisában segítenek a következő esetekben:
* megfelelő objektumokat megtalálni, definiálni (tervezés során nem minden objektumot kapunk triviálisan a szöveges leírásból /szoftvertechnológián tanult módszerek/)
* újrafelhasználás
* változtathatóság, kiterjeszthetőség
b) '''Adapter'''

'''Cél:''' egy osztály interfészét olyan interfésszé konvertálja, amit a kliens vár. Lehetővé teszi olyan osztályok együttműködését, melyek egyébként az inkompatibilis interfészek miatt nem tudnánk együttműködni.

'''Példa:''' egy Grafikus editor működése közben a képernyőre lehet rajzolni a következő grafikus alakzatokat, melyek a ''Shape'' osztályból származnak: ''LineShape'', ''PoligonShape''. Szeretnénk továbbá egy ''TextShape'' alakzatot is. Ennek a megírása bonyolult, viszont a használt keretrendszerünk rendelkezik egy ''TextView'' osztállyal, mely hasonló funkciókat valósít meg, mint ami nekünk a ''TextShape'' -hez kellene, viszont nem tudjuk egy-az-egyben hasznát venni, mert nem implementálja a ''Shape'' osztályt (nem kompatibilis).
'''Megoldás:''' adapter minta használata. Felveszünk egy ''Shape'' -ből származó ''TextShape'' osztályt, melynek metódusai megfelelnek az elvártnak (nyilván, hiszen a ''Shape'' -t implementáljuk). A ''TextShape'' osztály tartalmaz egy referenciát egy ''TextView'' objektumra, és a megfelelő metódushívásokat ezen keresztül delegálja a ''TextView'' osztálynak.

https://wiki.sch.bme.hu/pub/Sandbox/OlahPeterSandbox/adapter_design_pattern.png

Az ábrán szereplő osztályok és szerepük:
* az Adapter tartalmaz egy pointert vagy egy referenciát az Adaptee-re
* az adapter delegálja a művelet végrehajtását az Adaptee-re
* a Target osztály, aminek meg kell felelnünk

==7. Ismertesse az MVC (Model-View-Control) vagy a Dokumentum/Nézet (Document-View) architektúrát. Ennek keretében rajzolja fel a minta osztály és szekvenciadiagrammját. Adja meg az egyes osztályok szerepét! (14p)==
===Document-view architektúra===
Az architektúra 2 szereplője: Document és View. A Document feladata az adatok tárolása és menedzselése. Olyan osztályok mely, az adatokat a tagváltozóikban tárolják, és olyan tagfüggvényekkel rendelkeznek, melyek kezelik ezeket az adatokat és elérhetővé teszik más osztályok számára. A View feladat az adatok megjelenítése, a Document adatai alapján. A felhasználói interakciók során általában a nézet a dokumentum tartalmát módosítja; általában egy tab-fülként vagy egy ablakként jelenik meg. Elve: az adat megjelenítésért és annak kezeléséért felelős kód szétválasztása 2 részre.

https://wiki.sch.bme.hu/pub/Sandbox/OlahPeterSandbox/d-v.png

A szekvencia diagram úgy néz ki, hogy a Document példány kap egy UpdateAllViews() metódus hívást, mire az sorra meghívja View példányok Update() metódusát. Ha felhasználói interakció történik, akkor a View is tud jelezni a Document felé (setData()) /?/.

===MVC architektúra===

Alapigazság: de drótozzuk be a GUI-ba az alkalmazás logikát. Szereplők: Model (alkalmazás logika), View(megjelenítés) és Controller(interakció - kommunikáció a felhasználóval).

https://wiki.sch.bme.hu/pub/Sandbox/OlahPeterSandbox/mvc.png


Modell: tartalmazza az adatokat, valamint olyan műveleteket, melyek ezeken az adatokon dolgoznak. 
View: megjeleníti az adatokat. Az adatokat a modellből olvassa ki, nem ő tárolja azokat. Tartalmazhat olyan adatokat, ami csak a nézetre vonatkozik (pl. Zoom értéke) 
Controller: A felhasználói interakciót kezeli. Felhasználó által keltett események, melyek ezen keresztül a modellt vagy a viewt hívják. 
Observer: ha egy controller megváltoztatja a modellt, akkor a modell valamennyi view-t és controller-t értesít, hogy frissítsék magukat a modellből. Ez garantálja a konzisztenciát. 

Ehhez nem találtam szekvencia diagramot, csak szöveges leírást:
* A controller kezeli az eseményeket
* A controller értesíti az eseményről a modellt
* A modell értesíti a változásról a view-(ka)t
* A view/view-ek lekérdezi(k) a modell állapotát és az alapján frissül(nek)

==8. ASP.NET kiszolgáló oldali vezérlők (jellemzők, szerepük, működésük, példakód) (14p)==
A felületelemek megjelenítéséért és viselkedéséért felelnek. Feldolgozzák a kliens oldalról érkező adatokat (pl. gomb nyomás esemény, elérhetővé teszik a böngésző által küldött felhasználói adatokat). Generálják a kliensnek küldendő HTML kódot (minden HTML kódra képződik le).

pl. TextBox létrehozása:
<pre>
<asp:TextBox ID="tID" runat="server"></asp:TextBox>
</pre>

* tID névvel lehet elérni a mögöttes kódból (.NET objektum)
* aspx fájlból HTML kódok segítségével testre-szabható a megjelenésük

Műdköés:
* első lekéréskor lefordul az aspx és a code-behind fájl egy temp könyvtárba DLL formájában
* a lefordított kód feldolgozza a bejövő kérést és előállítja a választ
* későbbi kéréseket a már lefordított kód szolgálja ki

-- [[KoczkaTamas]] - 2010.05.25.

-- [[OlahPeter|pepe]] - 2011.05.30.

[[Category:Infoalap]]