NET Microsoft.Net Framework és programozása II

.Net 2 előadás jegyzet – 4. óra

1.oldal

.NET Microsoft .Net Framework és programozása II. Előadás jegyzet Előadó: Pócza Krisztián ELTE,2012

ASP .NET I. fejezet A HTTP http  Az Interneten található webes tartalom eléréséhez általában http protokolt használnak a kliensek. A Hypertext Transfer Protocol (HTTP) egy kérés-válasz alapú protokol, ami azt jelenti, hogy ha a kliens elküldte a kérését, akkor erre a szerver válaszol, és ott befejeződik a kommunikáció. Nem foglalja le folyamatosan a szervert, csak a kiszolgálás idejére. A HTTP stateless, azaz állapotmentes: ha pl. két kérést intézünk egymás után ugyanarról a gépről ugyanarra a szerverre, (alapesetben) nem fogja tudni a szerver, hogy a kérés ugyanattól a klienstől érkezett. Más szóval: nem jegyez meg semmilyen információt. Javítások

Pl:



Cookie-k: A web-szerver ágyazhat olyan információkat a kérésre adott válaszba, amik a kliens oldalon eltárolódnak. Ha újra hívjuk az oldalt és a cookie ideje még nem járt le, akkor a következő kérésnél már a cookie -kat is felhasználja, így sok terhet vehet le a vállunkról (pl. nem kell újra authentikálni).



Querystring -be ágyazás: A querystring az URL mögé konkatenált string, ami a kérés mellett többletinformációt is tartalmaz, pl. paramétereket. Ha ide a Session Identificater -t ágyazzuk sid = <szám> formában, akkor szintén azonosíthatjuk a munkamenetünket.



Elrejtés a header -be: Ha az előző pontban szereplő sid-et a header -be rejtjük el, akkor egy sokkal elegánsabb megoldást kapunk. Start / Run: cmd > telnet avalon.inf.elte.hu 80 > get HTTP /1.0 > head /default.aspx HTTP /1.0

Az érkező válaszban szöveges formában szerepel, hogy milyen cookie -kat küldött.

.Net 2 előadás jegyzet – 4. óra

2.oldal

A formok esetén az adatok átadása kétféle módon történhet: GET vagy POST módszerrel. GET módszer esetén az adatok az URL-ben kerülnek átadásra egy kérdőjel után: script.php?nev=Jani&szulhely=Budapest POST -olt adatok esetén pedig a HTTP fejlécben küldődnek át, így a külső szemlélő számára láthatatlanok. HTML Hypertext Markup Language: Egyszerű leíró kódnyelv, amellyel platformfüggetlen, hivatkozásokkal ellátott dokumentumokat lehet készíteni. A HTML fájlok egyszerű ASCIIszövegfájlok (leírókódok formájában megadott) beágyazott kódokkal, amelyek a formázást és a hiperszöveges hivatkozásokat jelölik. A HTML -t használták (és részben még mindig) weblapok leírására. XHTML: Lényegében well-formed XML alapú HTML. Egyre elterjedtebb, a modern weblap szerkesztők már ilyet (is) elő tudnak állítani. Az ASP 2.0 is tudja az XHTML-t. A validator.w3.org -on lehet ellenőrizni, hogy megfelel-e a szabványnak. Pl: HTML: XHTML:





//sortörés

ELTE

Ez már HTMLben is well-formed volt, ezért XHTML-ben is megmaradt ez.



Az XHTML-ben kötelező az alt TAG kitöltése. (HTML-ben is ajánlott volt, de itt kötelező)

Illik stíluslapokat használni (CSS), mert átláthatóbbá és karbantarthatóbbá teszi az oldalt. A modern irányzat  Táblázatok helyet DIV-ek alkotják az oldalt Probléma  A CSS-t és DIV-eket különböző képpen értelmezik a böngészők, ezért néha széteshet az oldal. Scriptek Eszköz arra, hogy a felhasználó által bevitt adatot a szerver oldalon dolgozzuk fel. Common Gateway Interface (CGI): Az adatokat kétféleképpen küldhetjük el:  QueryString: URL-hez konkatenálódik  POST: A szerver környezeti változóira képződik le Personal Home Page (PHP)  Dinamikusabb oldalakat hozhatunk létre a segítségével (elég elterjedt, de elég szimpla… kezelés, áttekintés, módosítás, stb. nehéz). PHP, Python, Pearl környezeti változók helyett indexekben és változókban tárol adatokat (jobb).

.Net 2 előadás jegyzet – 4. óra

3.oldal

ASP .NET Próbálja követni a WinForm-os filozófiát. Visal Basic .NET, vagy C# kódot írhatunk XHTML -be. Szétválik a design (MyProgram.aspx) és a logikai rész (MyProgram.aspx.cs). (Kis bug a VS 2005 –ben  Nem az oldal mellé teszi a solution fájlt, hanem a Projects könyvtárba) Támogatja a: - cache -elést - session kezelést - data binding Fontos hogy elválasszuk egymástól: - a felhasználói felületet, illetve a megjelenítést (user interface) - az üzleti logikát (bussines logic) - adatelérési réteget (data access) Alap: magas szintű markup language – az ASP .NET interpreter átfordít HTML-re. Ez a markup language böngésző-független. Amikor az oldalt megnézi valaki, akkor a böngésző elküldi a saját verzióját és ez szerint állít elő kódot. ASP .NET application készítése Visual Studio -ban New..  Project  Web Applicaton  ASP .NET web application  Saját webszervere van a teszteléshez.  Nem a 80-as portot használja.  Nincs szükség IIS szerver telepítésére fejlesztésnél.  Amit szerkesztünk, az a Default.aspx.  Van még Web.Config.cs – de nagy részére nincs szükségünk.  Fejlesztéskor SPLIT mód – fent látom kódot, alul pedig hogy milyen lesz a weboldal ASP .NET MVC 2010 újdonsága a webfejlesztés területén az ASP.NET MVC, vagyis Model View Controller. Az MVC teljesen objektumorientált webfeljesztési technológia, ahol többé nem válik a programozó számára az objektum adattá, az adat stringgé és vissza. Először tisztázzuk mi is ez? Egy ingyenes és teljesen supportált Microsoft framework olyan webes alkalmazások fejlesztéséhez, amelyek az MVC modellt valósítják meg. Az MVC tehcnológiához nyújt ismertetőt az alábbi link: http://hu.wikipedia.org/wiki/Modell-nézet-vezérlő Ezt le kell töltenünk a hivatalos ASP.NET MVC honlapról. Amint sikeresen telepítettük a kiegészítést a Visual Studio-t elindítva a File  New Project  Web résznél máris láthatjuk az új templatet: ASP.NET MVC Web Application. Nincs is más dolgunk, mint elkészítjük az első MVC web site-unkat. Némi gondolkodás után a már megszokott Web project tárul elénk, de azonnal észrevehetünk néhány eltérést. Ezek például a megszokottnál több mappában (pl.: Modell, View, Controller mappák) vehetőek észre. Ezeket kinyitogatva pedig újabb meglepetés vár ránk, kaptunk MasterPage-t, About, Login, Regiszter, stb. weblapokat (gyakorlatilag egy form authentication alapú website). Ezt akár rögtön futtathatjuk is, nem sokat fogunk látni, a lényeg

.Net 2 előadás jegyzet – 4. óra

4.oldal

az alap funkciók MVC alapon való megvalósításának bemutatása. Nyílván senki sem fogja a kapott MasterPage-t és oldalakat használni, esetleg nem is form authentication kíván alkalmazni. Ezért ajánlott az alap projectet átalakítani, kitörölgetni belőle a számunkra felesleges oldalakat, és vezérlő osztályokat, mesteroldalt, stb.… És most jön a trükk, ami segít nekünk, hogy ezt ne kelljen többször elvégezni: File  Export Template… menüpontot kiválasztva egy varázsló jelenik meg. Első lapján a „Project Template”-t kell választanunk, és ha van több projectünk is a Solutionban, akkor meg kell adni az MCV alkalmazást. Következő oldalon megadhatunk ikont, template nevet és leírást. Innentől kezdve az új projectek között megtaláljuk saját MVC -nket is. Érdemes és ajánlott a technológia elsajátítását a Microsoft honlapján kezdenünk, ahol azért elég jó betekintést adnak a keretrendszer használatához: http://www.asp.net/mvc/learn/ Form készítés, Controlok Eszköztárról a webformra húzzuk a dolgokat, property -k ugyanúgy, mint Winform esetében. Az eszköztárnál két féle eszköz  Standard ASP | HTML A HTML-es dolgokra nem lehet a szerver oldalon hivatkozni. Ez növelheti a teljesítményt, mivel ezzel nem kell foglalkozni a szervernek. EnableViewState  A forrás első sorába írva beállíthatjuk, hogy az oldal emlékezzen-e a beállított állapotokra egy újratöltés esetén. Hidden elementbe tárolja le az állapotokat. Probléma: Nagyon megnőhet a hidden element stringje, ha sok a kontrol. Megoldás: minden kontrolra külön állítható ez a tulajdonság. IsPostBack  Ha másodszor, harmadszor, stb. kérjük le ugyanazt az oldalt elnavigálás nélkül (pl. visszaküldünk információt a szervernek), akkor lesz igaz. Ezzel megoldható, hogy egy lista csak egyszer töltődjön fel, ne minden újratöltés esetén. (Default: False) If not Page.IsPostback then … End If Van AutoPostBack property is – hasznos lehet pl. DropDownList esetén. ViewState A ViewState kliens oldalon tárolja a control-ok állapotát. - A submit-elendő elemek állapotát ViewState nélkül is visszaállítja a rendszer. - A nem visszaküldött elemek értékét tudja ez alapján visszaállítani. Kliens oldalon tárolja az értékeket, ezért: - A szerver oldalon nem igényel plusz memóriát. - Erősen igénybe veszi a hálózatot. - A szervernek minden kérésékor fel kell dolgoznia a kódolt állapotot. - Biztonsági kérdések merülnek fel (ezért szokták néha kikapcsolni).

.Net 2 előadás jegyzet – 4. óra

5.oldal

Az oldal életciklusa Minden vezérlő egy object (ld. default.aspx.designer.cs). Minden lapküldésnél új objectet hoz létre. Ezért nem jó inicializálásra a konstruktor. A program indítása A következő függvények, események egymás után hívódnak meg a programunk indításakor és rendre az alábbi sorrendben követik egymást: * Application_Start * Application_BeginRequest * Application_AuthenticateRequest * Session_Start * OnInit * Page_Load * Page_PreRender * Page_Unload * Application_EndRequest Az Application osztály Start eseményéről tudnunk kell, hogy az csak a programunk első indulásakor fut le. A továbbiakban (amíg az alkalmazásunk fut) ez az esemény már nem kerül meghívásra. Egy gombra történő kattintás Amikor a weblapon lévő gombra kattint a felhasználó, akkor egy PostBack történik, így egy újabb kérést kap az alkalmazásunk. Ekkor az alábbi sorrendben kapjuk az eseményeket: * Application_BeginRequest * Application_AuthenticateRequest * OnInit * Page_Load * Button1_Click * Page_PreRender * Page_Unload * Application_EndRequest Validáció (Mire jó?) Célja  Ellenőrizni, hogy a bevitt adatok egyáltalán lehetnek-e helyesek. Meg van-e adva minden adat, típus megfelelő-e, stb. Validálni szerver és kliens oldalon is szükséges, mert HTTP kéréseket kézzel is össze lehet rakni (megkerülve a böngészőt és ezzel a validációt). Ha a szerveren nem validálnánk, akkor lehetőség lenne a hackelésre. Kliens oldalon is szükséges validálni, mert felesleges terhelni a hálózatot és a szervert, ha biztos, hogy rossz adatot készülnek bevinni. Csak az a kontrol okoz validációt, amelynek a property-jében true a következő: CausesValidation.

.Net 2 előadás jegyzet – 4. óra

6.oldal

Validáció (Hogyan?) Eszköztár  Validation  Többféle validátor típus: RequiedFieldValidator, ReqularExpressionValidator, CompareValidator, RangeValidator stb. (továbbá van lehetőség saját validátor definiálására is). Hozzá kell kötni egy kontrolhoz (tipikusan Textboxhoz), majd meg kell adni, hogy mi legyen a hibaüzenet akkor, ha nem valid az oldal. Session A session egy webszerver alapú megközelítés az állapotok megőrzésére. Egy session a web szerver memóriájában tárolja az adatokat ideiglenesen, amíg a felhasználói munkafolyamat véget nem ér. Egy session megőrzi az adatokat akkor is, ha az oldal újratöltődik (pl. egy POSTBACK miatt). Hátránya, hogy sok session-nél, lecsökkenhet a webszerver memóriája. ASP .NET-ben: Session nevű hashtábla áll rendelkezésre. Global.asax Add new item  Global… Általános eseményekre definiálhatunk tennivalókat (programkód formájában), mint pl alkalmazás indulása, megszűnése, Session indítása, vagy megszűnése. Pl.:  Számolhatjuk, hogy hány session indult és egy bizonyos szám felett nem engedünk meg többet.  Csak egyszer írjuk ki, hogy „Üdvözöljük a felhasználót a weblapon” amikor belép, és utána nem.  Állandóan érvényes adatokat állíthatunk be, illetve tárolhatunk, méghozzá alkalmazás szinten. Pl: Application Start() protected void Application_Start(object sender, EventArgs e) { Application["fontosAdat"] = 1234; Application["countSessions"] = 0; }

Cache kezelés Alkalmazás szintű Cache. Olyan adattároló, amiből idővel „elpárologhatnak” az adatok Egy adat kikerül, ha: - a terhelés nagy (nagy adatforgalom) - a csúszó határidő (pl. 5 perc) után, hacsak nem kérdezik le újra - az abszolút határidő esetén mindenképp kikerül akkor is, ha azt újra lekérdezték (legelsőtől számít!) Ha a Cache-ben egy érték NULL és azt kérdezem le, akkor megnézi van-e adat és azt azonnal belerakja (nem lehet csak megnézni külön, hogy benne van-e, hiszen idő közben megváltozhat).