Acest articol reprezintă primul episod dintr-o serie de tutoriale ASP.NET care sunt gândite pentru programatorii începători (cel puțin din punctul de vedere al ASP.NET-ului), dar prezintă componente interesante și pentru programatorii avasați. Printre subiectele pe care le vom aborda:
· Dezvoltarea interfeței unei aplicații web ASP.NET.
· Păstrarea stării în aplicații web.
· Lucrul cu baze de date.
· Securitate.
· Instalare și configurare.
Ce este ASP.NET?
ASP.NET este un set de tehnologii care ne permit crearea de aplicații web. Este evoluția de la Microsoft Active Server Pages (ASP), dar beneficiază de suportul platformei de dezvoltare Microsoft .NET.
Una dintre cele mai importante calități ale ASP.NET este timpul redus necesar dezvoltării aplicațiilor web. Atât tehnologia în sine, cât și uneltele de dezvoltare de aplicații web de la Microsoft (cum ar fi Visual Web Developer Express - VWD) – reduc considerabil timpul de dezvoltare al aplicațiilor web față de alte tehnologii – prin simplitatea unui limbaj de programare ”managed” de genul C# sau Visual Basic .NET, prin colecția bogată de biblioteci de clase și controale .NET care oferă foarte multă funcționalitate ”out of the box”, prin orientarea pe construirea de aplicații web a mediului de dezvoltare VWD.
Chiar dacă ASP.NET este gândit pentru a dezvolta aplicații web foarte complexe – prin faptul că se bazează pe .NET, prin faptul că se insistă pe un model de dezvoltare OOP, respectiv pe separarea interfeței de logica aplicației – totuși, este extrem de simplu ca folosind ASP.NET să dezvoltăm aplicații mici, de genul magazinelor online, al aplicațiilor care sunt pur și simplu un ”front-end” pentru o bază de date, sau al site-urilor personale.
Introducere în ASP.NET
Programarea
ASP.NET cuprinde toate tehnologiile necesare pentru a dezvolta o aplicație web, scriind cantitatea minimă de cod. Limbajele de programare care pot fi utilizate pentru a crea aplicații ASP.NET sunt cele suportate de platforma .NET – cum sunt Visual Basic .NET și C#, iar o altă caracteristica importanta a acestor limbaje (înafara faptului că sunt ”managed”) este ca au fost create având în vedere paradigma programării orientată pe obiecte. Totul din .NET, și evident din ASP.NET, este un obiect.
Structura paginilor
Orice pagină ASP.NET presupune 2 componente: (1) partea vizuală – controalele propriuzise care vor fi vizualizate de către utilizator, (2) codul .NET care va fi executat pe server atunci când se face o cerere către respectiva pagină.
Deși putem alege modul în care se stocheaza pe hard-disc cele două componente (un singur fișier sau unul pentru fiecare componentă), recomandăm să alegem varianta a doua, cea în care pentru fiecare pagină ASP.NET se crează un fișier de tipul < nume_pagină>.aspx și unul de tipul < nume_pagină>.aspx.cs (dacă proiectul nostru este dezvoltat cu C#) sau
Controale pentru interfața cu utilizatorul
Ca orice tehnologie modernă pentru dezvoltarea de aplicații web, ASP.NET vine cu o serie de controale, de la butoane și liste de selecție, până la controale avansate de genul celui pentru autentificare. Pe lângă setul foarte complet de controale, ASP.NET permite programatorului să dezvolte propriile sale controale, pornind de la cele existente. În principiu, programatorul poate să încapsuleze într-un control propriu absolut orice funcționalitate permisă de o aplicație web.
Găzduirea aplicațiilor ASP.NET
Evident, orice site / aplicație web trebuie să fie găzduită pe un server pentru a putea fi utilizată. Chiar dacă în capitolele viitoare vom discuta mai mult despre instalarea aplicațiilor ASP.NET, aici aș dori să prezint pe scurt variantele de găzduire.
Pentru o persoană / companie care dorește să beneficieze de o aplicație ASP.NET, după ce a fost dezvoltată, trebuie instalată undeva. Presupunând că ea a fost dezvoltată pentru .NET (și nu Mono de exemplu, vezi mai jos la Interoperabilitate), aplicația are nevoie de un server web IIS (internet Informations Services).
Există două variante de a găzdui aplicațiile ASP.NET: (1) intern, pe serverele proprii sau (2) extern, la o firmă care oferă servicii de găzduire (hosting). Decizia trebuie luată ținănd cont de câțiva parametri:
· Costul de mentenanță. Intern costă administrarea serverelor cu tot ce presupune asta: hardware, software, specialiști. Extern costă un abonament fix pe lună/an.
· Securitatea. Dacă vorbim de o aplicație extrem de importantă și care manipulează informații sensibile, probabil vom dori să fie sub controlul propriu.
· Etc.
Pentru programatorii care doresc să aibă un site dezvoltat din pasiune sau pentru a învăța, dar vor totuși să îl aibă instalat undeva, variantele de mai sus devin: (1) acasă, pe Windows XP / Vista cu IIS; (2) la o firmă care oferă servicii de hosting gratuit. Da, există variante de acest gen, unde vă puteți instala propriul site ASP.NET fără să vă coste nimic (căutați pe www.live.com ”asp.net free hosting”).
Demo şi screencast
Colegul meu Ştefan Filip de la H.P.C. Consulting, a pregătit un demo (http://www.hpc-consulting.ro/code/Tutorial1/HelloWorld.zip ) şi un screencast (http://www.hpc-consulting.ro/code/Tutorial1/01.%20Introducere%20in%20ASP%20.NET.wmv ).
Introducere în ASP.NET pentru avansați
Compilarea
Atunci când un utilizator acceseaza o pagină a unui site web dezvoltat cu ASP.NET, cererea respectivă este trimisă de IIS (Internet Information Services – serverul web de la Microsoft) către ASP.NET pentru procesare. Acesta compilează pagina respectivă în format MSIL (Microsoft Intermediate Language) care apoi este procesat de către Common Language Runtime (componenta din .NET care se ocupă de execuția codului). La cereri succesive către aceeași pagină, aceasta nu mai este compilată din nou, ci este executat direct codul intermediar MSIL.
Execuția și performanța
Managementul memoriei
Codul ASP.NET rulează într-un singur proces (w3wp.exe în IIS6). Cererile către server sunt introduse într-o coadă de așteptare și sunt executate pe fire de execuție diferite, folosindu-se un mecanism de ”thread pooling”, adică de reutilizare a firelor de execuție pentru a nu reduce semnificativ performanța cu timpii relativ lungi de a crea câte un fir pentru fiecare cerere.
Platforma Microsoft .NET vine cu un mecanism de Garbage Collection, care are rolul de a distruge obiecte care au fost create și care nu au mai fost folosite de ceva timp. Acest ”de ceva timp” este un termen ambiguu, dar GC are un mecanism prin care clasifică obiectele în funcție de momentul în care au fost create și de durata față de ultimul acces la acestea, distrugându-le pe cele mai vechi, crescând ca importanță (și prin urmare scăzând timpul maxim permis pentru un obiect să stea în memorie după ultimul acces) pe măsură ce memoria este folosită mai intens.
GC în aplicațiile ASP.NET îngheață (blochează) toate firele de execuție care au menirea de a procesa cereri, până termină de curățat obiectele vechi, acest lucru petrecându-se folosind niște fire de execuție speciale, cu prioritate ridicată.
ASP.NET a fost gândit ca o extensie ISAPI (Internet Server API) pentru IIS5 și IIS6, iar în IIS7 poate să ruleze și în modul Integrated Pipeline.
Dar, mai întâi despre ISAPI. Pe scurt, este o API menită a oferi programatorilor posibilitatea de a extinde facilitățile IIS-ului. O extensie ISAPI este un dll care colaborează cu IIS (prin API-ul menționat) și care odată încărcat în memoria IIS-ului, va ramâne acolo și la următoarele cereri adresate lui. Aceasta este o deosebire fundamentală față de CGI (Common Gateway Interface) – care în esență permite crearea unui executabil in C, C++, Perl, etc și care este încărcat, executat și descărcat din memorie la fiecare cerere primită.
Cu alte cuvinte, aspnet_isapi.dll – extensia ISAPI care încapsulează funcționalitatea ASP.NET este încărcat în memorie o dată și ramâne acolo atât timp cât există cereri pentru ASP.NET – ceea ce este o îmbunătățire majoră de performanță față de CGI, putând afirma că cel puțin din acest punct de vedere aplicațiile ASP.NET sunt mult mai performante decât cele dezvoltate prin CGI.
După ce o cerere pentru un site ASP.NET venită de la utilizator, trece prin IIS și este trimisă către aspnet_isapi.dll, intră în joc un pipeline de ASP.NET. Astfel, cererea este trecută printr-o serie de module HTTP (cum sunt Session, Output Cache, Authentication, etc), iar în final cererea ajunge la handlerul HTTP specific cererii. Handler-ul HTTP este cel care în cele din urmă interpretează cererea, și este ales pe baza extensiei fișierului adresat. De exemplu, .aspx reprezintă o pagină ASP.NET și declanșează handlerul specific paginilor, .asmx reprezintă un serviciu web și declanșează un alt handler, etc. În final, după procesarea specifică handler-ului, rezultatul este retrimis către server și în cele din urmă către utilizator sub formă de HTML.
În IIS7, există posibilitatea ca pipeline-ul ASP.NET să se suprapună peste cel al IIS-ului. Folosind IIS7, modulele ASP.NET pot să ruleze înainte de funcționalitățile IIS sau chiar să le înlocuiască. Un exemplu în care ASP.NET poate interveni înainte de IIS este dezvoltarea unui modul de ”basic authentication” care utilizează să spunem o bază de date SQL Server și care să îl înlocuiasca pe cel al IIS-ului (care merge numai cu conturi de Windows).
Din cauza acestei integrări, IIS7 și ASP.NET pot să folosească aceleași configurări pentru modulele și handlerele HTTP. De asemenea, se pot unifica funcționalități ca: tracing, erori customizate, cache la nivel de pagini.
Caching
ASP.NET permite caching-ul pe mai multe nivele.
În primul rând, la nivel de pagini. Dacă avem pagini cu conținut static, deci care nu se modifică în timpul execuției, are sens să luăm în considerare opțiunea de a salva conținutul acestora pe server, pentru a fi servite direct, fără procesarea request-ului.
Chiar mai mult, avem opțiunea de a efectua ”partial cache” în situațiile în care doar anumite componente ale unei pagini sunt statice, iar restul sunt dinamice.
În al treilea rând, ASP.NET ne oferă posibilitatea de a salva date / stare de obiecte la nivelul memoriei IIS. De exemplu, atunci când citim din baza de date o listă de elemente, și lista respectivă este mai mult sau mai puțin constantă în timpul execuției, are sens să o salvăm in cache-ul ASP.NET pentru ca la cereri succesive să fie luată de acolo fără a mai interoga sursa de date (server de baze de date, fișier, serviciu web, etc.).
Controale și ViewState
Controalele ASP.NET au o proprietate extrem de importantă din punct de vedere al performanței: își păstrează starea între postback-uri. ViewState-ul, căci despre el e vorba, ne ajută din acest punct de vedere, dar prezintă și dezavantaje care vin cu stocarea stării controalelor: dimensiunea paginii este mai mare, valorile trebuie serializate / deserializate la salvare / citire din ViewState, etc. Partea bună a lucrurilor este faptul că ViewState-ul poate fi dezactivat atunci când se consideră că nu este necesar. Dar, mai multe despre acest subiect în episoadele viitoare.
Lucrul cu bazele de date
Chiar dacă acest subiect ține mai degrabă de componenta ADO.NET, este destul de uzual ca în aplicațiile web ASP.NET să se lucreze cu baze de date, și de aceea vom aloca un episod acestui subiect. Până atunci, legat de performanță menționăm funcționalitatea numită ”connection pooling” care are abilitatea de a reutiliza conexiuni la baza de date. Cu alte cuvinte, dacă avem 100 de utilizatori simultan conectați la aplicație, și fiecare cerere din cele 100 fac la un moment dat un apel la baza de date, asta nu înseamnă că se vor deschide 100 de conexiuni la serverul de baze de date, ci mult mai puține.
Interoperabilitatea
ASP.NET face parte din platforma Microsoft .NET și deci poate să ruleze pe sistemele de operare pe care aceasta poate să ruleze. Acestea sunt toate versiunile de Windows de la 2000 încoace.
În ceea ce privește alte sisteme de operare, există opțini și acolo. Datorită faptului că Microsoft .NET reprezintă implementarea de la Microsoft pentru niște standarde deschise, asta a permis ca alte implementări să fie realizate, cea mai cunoscută dintre ele fiind Mono (http://www.mono-project.com/Main_Page ). În mare parte, aplicațiile .NET care au fost dezvoltate folosind C# / .NET / Visual Studio / Windows, pot fi compilate Mono pentru sisteme de operare altele decât Windows. Spunem ”în mare parte”, pentru că există unele zone în care diferențele dintre sistemele de operare sunt majore (de exemplu modul în care au fost implementate interfețele grafice în sisteme de operare diferite).
Search engine optimization
Una din facilitățile pe care o aplicație web trebuie să le aibă, este să ofere motoarelor de căutare ușurința de a indexa conținutul. Unul din aspectele care în trecut erau destul de controversate vis-a-vis de ASP.NET și IIS este posibilitatea de a rescrie URL-urile a.î. să fie prietenoase pentru căutare. De exemplu, avem o pagină cu conținut dinamic – să spunem o pagină ce încarcă dinamic conținutul unor articole, pe baza unor parametri din QueryString: http://localhost/UrlRewriteApplication/Default.aspx?param1=articol1 .
Unde, articol1 este să spunem numele unui articol stocat în baza de date, pe care pagina îl afișează. Url-ul de mai sus nu este prietenos pentru motoarele de căutare, dar un Url de forma următoare ar fi mai ușor de indexat: http://localhost/UrlRewriteApplication/RewritePages/articol1.aspx . Scopul urmărit de o aplicație web ar fi ca primind un Url ușor de indexat, să îl transforme într-un Url specific aplicației ca să îl poata interpreta. Facilitatea respectivă, cunoscută şi sub numele de mod_rewrite, nu apare intrinsec în IIS – dar poate fi dezvoltată foarte ușor încă de la ASP.NET 2.0 / IIS6. În exemplul următor vom realiza această funcționalitate cu ASP.NET 3.5 și IIS7.
