Website Aplicatie Rezervari Bilete

Aplicație WEB pentru rezervare de bilete online

Cuprins:Administrarea paginilor WEB folosind ASP.NET..........................................................................................5

Introducere în aplicații WEB....................................................................................................................5

Comunicarea cu serverul.........................................................................................................................7

Limbajul XHTML.......................................................................................................................................9

Formulare................................................................................................................................................9

ASP.NET.................................................................................................................................................11

Ce e gresit la ASP-ul clasic?................................................................................................................11

Limbajele de scriptare.......................................................................................................................12

Ce aduce ASP.NET?............................................................................................................................12

Tipuri de fișiere în ASP.NET................................................................................................................13

Modelul de cod..................................................................................................................................14

Controale Web și controale HTML.....................................................................................................15

Postback............................................................................................................................................15

Menținerea stării prin Viewstate......................................................................................................16

Ciclul de viață al unei pagini...............................................................................................................17

Forme Web și colecția de controale din pagină................................................................................18

Request..............................................................................................................................................18

Response...........................................................................................................................................18

Server................................................................................................................................................19

Controale server HTML......................................................................................................................20

Controale Web server........................................................................................................................21

Gestiunea starii în ASP.NET................................................................................................................22

Query String.......................................................................................................................................22

Cookies..............................................................................................................................................23

Sesiunea............................................................................................................................................23

Application.........................................................................................................................................24

Validatoare........................................................................................................................................24

Pașii de validare.................................................................................................................................25

Clasa BaseValidator...........................................................................................................................25

Validatorul RequiredFieldValidator...................................................................................................26

Validatorul RangeValidator................................................................................................................26

Validatorul CompareValidator...........................................................................................................26

Validatorul RegularExpressionValidator............................................................................................27

Controlul CustomValidator................................................................................................................27

Controlul ValidationSummary............................................................................................................27

Grupuri de validare............................................................................................................................27

Cascading Style Sheets.......................................................................................................................28

Teme..................................................................................................................................................28

Pagini master.....................................................................................................................................29

Legarea la date..................................................................................................................................30

Elemente de bază JavaScript.............................................................................................................30

ASP.NET membership........................................................................................................................31

Crearea unei pagini de login..............................................................................................................32

NHibernate................................................................................................................................................32

Avantajele folosirii NHibernate.............................................................................................................33

Fișierul de mapare XML hbm.xml..........................................................................................................33

Expunerea bazei de date.......................................................................................................................34

Relaționare............................................................................................................................................35

Normalizarea.........................................................................................................................................36

Clase......................................................................................................................................................36

Proprietăți publice și variabile private..................................................................................................36

Proprietăți pentru chei străine.............................................................................................................37

Maparea datelor....................................................................................................................................38

Maparea XML....................................................................................................................................38

Maparea Fluent..................................................................................................................................39

Ce este o sesiune NHibernate?..............................................................................................................40

Session factory.......................................................................................................................................40

Crearea unei sesiuni în NHibernate.......................................................................................................40

Sesiunea NHibernate versus sesiunea bazei de date.........................................................................41

Sesiuni în ASP.NET.................................................................................................................................41

Configurare............................................................................................................................................41

Abstractizarea configurațiilor................................................................................................................43

Metode de acces ale obiectelor.............................................................................................................43

Structura FieldNames............................................................................................................................44

Obiectul ICriteria...................................................................................................................................44

Filtrare ICriteria.....................................................................................................................................45

Legarea datelor......................................................................................................................................46

Controlul <asp:ListView>.......................................................................................................................47

Controlul <asp:ObjectDataSource>.......................................................................................................47

Legătura directa.................................................................................................................................47

Controale intregrate..............................................................................................................................48

Securitatea locației................................................................................................................................48

Roluri pe bază de utilizatori...................................................................................................................48

Configurarea furnizorului......................................................................................................................49

Conversia template-urilor CSS...............................................................................................................50

Administrarea paginilor WEB folosind ASP.NET

Introducere în aplicații WEB

O aplicație Web este un program care este stocat pe un server Web,acesta putând fi accesat prin intermediul unui browser folosind rețeaua. La un capăt al acestei comunicații se află un server (program dedicat) care acceptă interogări, formulate prin protocolul HTTP, serverul putândsă servească pagini web statice (fișiere scrise în limbaj HTML) sau resurse statice (imagini, fișiere PDF etc.). Exemple de servere folosite în prezent:

Apache – este cel mai răspândit în acest moment; fiind capabil să ruleze pe o multitudine de sisteme de operare; conform Netcraft, în septembrie 2009, 54,48% din site-uri rulau Apache;

IIS = Internet Information Services, creat de către Microsoft pentru a fi folosit pe sistemele de operare Windows; disponibil pe windows 2000 (IIS 5), Windows XP Professional (IIS 5.1), Windows Server 2003 (IIS 6), Windows 2008 (IIS 7.0 și 7.5), Windows Vista anumite versiuni (IIS 7.0), Windows 7 anumite versiuni (IIS 7.5). IIS este folosit în dezvoltarea aplicațiilor ASP.NET. Conform Netcraft în luna precizată mai sus 19.91% din site-uri rulau o variantă de IIS.

La celălalt capăt, se afla un browser (fie el Internet Explorer, Mozila Firefox, Safari, Google Chrome sau Opera – cele mai utilizate la ora actuală. Utilizatorul trebuie să indice care adresa de Web la care se află pagina dorită.

Acestea doua formeaza un tip de comunicare numit client-server, clientul fiind browserul, iar serverul este cel care răspunde prin furnizarea unei pagini web(în cazul în care se poate). Browserul este de fapt un așa numit thin client1; nu necesită instalarea locală a unor componente (cu excepția browserului, utilizabil pentru toate site-urile), și nici drepturi de administrator pe mașina pe care lucrează.

1 Un calculator sau un program care depinde de alte calculatoare (server) pentru a-și realiza atribuțiile

Un avantaj al acestor aplicații web este faptul că dacă se schimbă o parte din aplicație, această modificare se face într-un singur loc –pe server. Clientul (browserul) fiind insensibil la această manevră și nu trebuie actualizat în niciun fel.

Nu este importantă platforma sau sistemul de operare pe care rulează browserul, deoarece paginile Web reprezintă doar text care este înțeles de către orice sistem. Există însă mici diferențe între modul în care un browser desenează pagina pe ecran.Acest lucru se datoreaza faptului că HTML reprezintă niște specificații despre cum ar trebui să fie desenat un anumit cod HTML, dar cei care creează browsere nu iau acest fapt ca pe o obligație.

Ca un neajuns al acestui tip de aplicații: dacă rețeaua devine indisponibilă, aplicația web nu poate fi accesată. Rezolvarea acestei situații se face print-un al treilea tip de aplicații (pe lângă cele thin și thick): smart applications2.

Modele clasice de realizare a aplicațiilor Web:

Soluția CGI3 - reprezintă o serie de scripturi executate peserverul we,ce pot fi scrise în orice limbaj de programare (interpretat sau compilat).Aceste trebuie să respecte următoarele restricții: programul scrie datele la ieșirea standard și nu genereaza antete care permit browserului să interpreteze corect ieșirea scriptului, conform specificațiilor HTTP. Se pot folosi limbaje precum bash, Perl, C/C++, Delphi. Neajunsul CGI-urilor îl reprezintă faptul că se crează unu nou proces pe serverul Web pentru fiecare cerere, ceea ce la un număr mare de cereri este prohitiv.

Soluția ISAPI4 - este o alternativă CGI pe platforma Windows. Dezvoltatorii Win32 pot scrie un program capabil să comunice direct cu această interfața pentru a face orice lucru posibil cu CGI, pot folosi ISAPI pentru a obține date din formulare și pentru a trimite conținut HTML la client. Codul la nivel de server poate fi scris în oricare limbaj cu suport pentru DLL-uri Windows, precum C/C++, Visual Basic, rezultatul compilarii fiind un fișier .dll. Spre deosebire de CGI, ISAPI rulează în același spațiu de adrese cu serverul HTTP, având acces la toate resursele serverului HTTP, pot fi incluse mai multe task-uri într-un .dll și nu creeaza procese adiționale pentru rezolvarea cererilor clienților Web.

Soluția PHP5 (1994) sau ASP6 (1996) marchează un salt în dezolvatarea aplicațiilor Web. Cele două limbaje diferă din punct de vedere al sintaxei, însa ambele sunt interpretate, codul lor fiind stocat în fișiere externe cu extensia .php/.asp. De fapt, ASP nu oferă un limbaj nou, ci se bazează pe limbajele VBScript și Jscript. Un fișier PHP/ASP poate fi combinat cu date de tip text, marcatori HTML și comenzi script, în momentul execuției,în urma cererii unui client Web, fișierul este procesat, fiecare script din cadrul lui este interpretat și rezultatul execuției este introdus înapoi în fișierul static HTML înainte ca rezultatul să fie trimis către browser. Limbajele pun la dispoziție o serie de metode și obiecte care ușurează lucrul cu cookie-uri, cu bazele de date, care preiau elegant intrările

2Aplicații ce pot rula și în mod deconectat având doar o parte din funcționalități active (client de email Outlook sau Mozila Thunderbird).3Common Gateway Inteface4Internet Server Application Programming Interface5Hypertext Preprocessor6Active Server Pages

unui formular HTML și le procesează la server, care preia informații despre utilizator (clientul Web), care trimit informații la utilizator, care stochează informații despre sesiunea unui utilizator, care partajează informații între utilizatorii unei aplicații.

JSP7- permite crearea de aplicații Web independente de platformă. Acesta separă interfața utilizator de conținutul generat dinamic, permițând shimbarea întregului șablon al site-ului WEB, fără a altera informațiile afișate. Tehnologia utilizează marcatori XML și scripturi scrise în limbajul de programare JAVA pentru a încapsula logica aplicației care generează conținutul paginilor Web. JSP-urile sunt o extensie a tehnologiei Java Servlet8. Servlet-ele sunt complet independete de platforma și reprezintă module la nivel de server ce se integrează în cadrul unei aplicații Web.Acestea pot fi utilizate pentru a extinde capabilitățile unui server Web. Tehnologia JSP și servlet-urile oferă o alternativă pentru crearea aplicațiilor Web, față de alte limbaje de scripting / programare a aplicațiilor WEB, oferind independență de platformă, separarea logicii aplicației de partea de interfață utilizator, administrare ușoară și extensibilitate.

Toate acestea au în comun faptul că serverul Web reprezintă o interfață de comunicare cu procese externe. Separarea software-ului în diferite procese oferă avantajul de modularizare și ușurează procesul de integrare și în același timp extinde funcțiile web server-ului.

Server IIS folosind ASP.NET pentru generarea de pagini Web dinamice.

Comunicarea cu serverul

7Java Server Pages8 O clasa a unui limbaj de programare folosit să extindă capabilitățile serverului, accesate de către aplicații de tip host.

Paginile web sunt de obicei transmise și primite prin intermediul Internetului via HTTP9(nesecurizat) sau HTTPS10(securizat).Dezvoltarea protocolului HTTP a fost supervizată de către World Wide Web Consortium.

HTTP este un standard de comunicare ce permite vehicularea de cereri și răspunsuri între client și un server. O cerere arată astfel:

linie de cerere, precum GET / images/logo.gif HTTP/1.1, care cere o resursă numită /images/logo.gif/ de pe server;

antete precum Accept-Language: en; o linie goală; un mesaj opțional.

Cele mai importante metode de cerere prin care un client solicită ceva de la un server suntget și post.

Un aspect esențial al comunicarii prin HTTP este faptul căHTTP este un protocol fără stare.Cu alte cuvinte, de cate ori un client efectuează o cerere către un server, acesta răspunde cererii după care ,,uită,, ceea ce a comunicat clientul; serverul nu menține nicio legatură cu browserul și nu menține resursele necesare pentru a raspunde clientului (cu o excepție minoră, mecanismul de keep-alive11 care permite reutilizarea unei conexiuni pentru alte cereri); dacă apar modificari ale pagini sau ale resurselor de date , atunci browserul nu este notificat în niciun fel.

Limbajul HTML12 este limbajul predominant folosit pentru crearea paginilor Web. Acesta descrie structura, conținutul și modul de apariție al unei pagini; poate să includă referințe către imagini, legatură către alte pagini, frame-uri, formulare și multe altele.

Conținutul unui document HTML este un document de tip text ce se crează pe baza unor elemente ( <p>, <a>, etc) care sunt definite de către limbaj. Un element are de obicei o etichetă de deschidere și una de închidere.

Browserul după primirea fișierului HTML va efectua o parsare a codului, de exemplu la întâlnirea unui element de tip img acesta face o cerere de tip get pentru a obține imaginea respectivă de pe server.

Limbajul XHTML13

9Hypertext Transfer Protocol10Hypertext Transfer Protocol Secure11Mesaj trimis de un dispozitiv către alt dispozitiv pentru a verifica daca link-ul dintre cele două este activ sau pentru a prevenii stricarea acestuia 12Hypertext Markup Language13eXtensible HyperText Markup Language – limbaj de marcare care are aceleași capabilități expresive ca și HTML

Acest limbaj hibrid a fost creat cu scopul de a prelua trăsăturile limbajului XML. Chiar dacă mai există pagini HTML, există o tendință constantă de a se produce numai conținut XHTML, chiar și uneltele de dezvoltare se conformează acestei tendințe.

Implicit conținutul generat de ASP.NET este de tip XTHML. Astfel elementele de marcare satisfac o serie de reguli:

etichetele și numele de atribute trebuie scrise cu litere mici; toate elementele trebuie să fie închise, fie cu un tag de închidere dedicat

(<p></p>) fie filosind un tag gol care se închide singur (<br />). toate atributele trebuie să aibe valorile incluse între ghilimele sau apostroafe

(id=”errorLabel”). atributul id trebuie să fie folosit în locul atributului name (dar controalele

ASP.NET generate vor avea amândouă aceste atribute, din motive de compatibilitate cu codul JavaScript existent).

elementele trebuie să fie imbricate corect: <p><a href="...">..</a></p> și nu <p><a href="...">..</p></a>.

documentele XHTML trebuie să aibe un unic element rădăcină; acesta este dat de eticheta html.

XHTML înlătură suportul pentru câteva mecanisme existente în HTML, cum ar fi frame-urile sau precizări stilistice care nu utilizeaza CSS14, sau folosirea atributului target pentru link-uri.

Orice document XHTML trebuie să înceapă cu o declaratie de tip de document, care definește tipul de XHTML folosit.

Formulare

Formularul este ce mai utilizată modalitate de trimitere de informații dinspre browser spre server. Formularul conține elemente care suportă specificarea de valori de către utilizator (cum ar fi numele și parola pe un formular de logare). Este de menționat faptul că dacă formularul conține și alte elemente (imagini, link–uri, text etc) acestea nu sunt trimise la server, deoarece ele nu poartă informație de la utilizator.

Un formular se declară folsind tagul <form>. Acesta are două atribute importante: action și method .

Atributul action arată care este pagina către care se va trimite conținutul formularului.

Atributul method arată care din metodele get(implicită) și postsunt folosite pentru a trimite valorile către server. Valorile posibile sunt get și post. Cu get toate datele din formular 14Cascading Style Sheets – un standard pentru formatarea elementelor unui document HTML

sunt adăugate la URL-ul specificat de atributul action. Partea de după semnul de întrebare din URL se numește query string15.

Există situații în care folosirea metodei get este contraindicată deoarece lungimea maximă a URL-ului este limitată de către browsere.

În cazul în care se specifică metoda post, atunci setul de date din formular se include în corpul formularului și este trimis mai departe la server. URL-ul nu va fi modificat. Există o diferență de comportament între get și post, getfiind considerat “idempotent”, adică acesta nu modifică starea serverului la trimiteri repetate ale aceleași interogări, pe când post e gândit pentru a produce efecte colaterale pe server – tranzacții financiare sau modificari de date.

În interiorul unui formular pot fi folosite următoarele elementele de tip input:

text - se folosește pentru crearea unor casuțe text, al căror conținut va fi furnizat de utilizator;

password – seamănă cu cele de tip text, cu diferența că în momentul în care cineva scrie în interiorul lui, caracterele sunt suprascrise cu un caracter inert;

checkbox – este folosit atunci când utilizatorul trebuie să specifice dintr-un set de opțiuni ne-mutual exclusive;

radio – permite alegerea a cel mult una din mai multe opțiuni; submit – modifică un text folosind atribului value; reset – realizează un buton pe care scrie textul ,,Reset,, și acesta va repune valorile

din formular la cele cu care au venit de pe server; nu se face trimiterea formularului la server. Arată ca un buton de tip Submit;

hidden - deseori este nevoie ca în cadrul formularului să existe niște date care să vină de pe server și să fie trimise înapoi odată cu restul datelor din formular. Aceste câmpuri sunt considerate ascunse, în sensul că nu au o apariție vizuală pe ecran;

image - input-ul de tip imagine creează un control imagine care, atunci când este apăsat trimite formularul către server. Locația imaginii este definită prin atributul src;

button - estece arată precum cel de Submit sau Reset,însă a cărui apăsare va fi procesată exclusiv prin cod JavaScript, în browser.

textarea - Input-ul de tip text este convenit a conține o singură linie. Pentru cazul în care se dorește existența unei casuțe text cu mai multe linii se poate folosi elementul textarea.

select - elementul select permite alegerea dintr-o listă derulantă a uneia sau a mai multor opțiuni. Lista de opțiuni este formată din perechi de forma cheie valoare, cheia (invizibilă în pagina desenată de browser) fiind cea care se trimite către server, iar valoarea este folosită pentru a face alegerea efectivă.

15Este o parte din link folosit pentru a trimite date către o altă pagină

ASP.NET

ASP.NET reprezintă o platformă pentru aplicații web, dezvoltată și distribuită de către Microsoft, pe care dezvoltatorii o folosesc pentru a contrui site-uri web dinamice și servicii web. A fost lansat în ianuarie 2002 cu versiunea 1.0 a .NET Framework și este succesorul tehnologiei Active Server Pages (ASP) dezvoltată tot de către Microsoft. ASP.NET a fost construit pe CLR16, ceea ce permite programatorilor să scrie cod folosind orice limbaj suportat de .NET.

ASP.NET este o tehnologie freeware17 de la Microsoft. ASP.NET poate fi folosit pentru a crea orice tip de aplicație web, începând de la mici site-uri personale până la cele de tip business. Strictul necesar pentru a programa cu ASP.NET este reprezentat de .NET Framework și de Visual Web Developer Express Edition, ambele gratuite.

Aplicațiile ASP.NET sunt aplicții web .NET complete care se execută ca și cod compilat gestionat de .NET runtime. ASP.NET folosește de asemenea capabilitațile complete a .NET Framework-ului – o gamă de clase la fel de ușor de înteles ca și cele pentru o aplicație Windows obișnuită. în esență, ASP.NET încearcă să estompeze linia între dezvoltarea de aplicații și dezvoltarea web prin preluarea instrumentelor și a tehnologiilor folosite de programatorii de aplicații desktop.

Ce e gresit la ASP-ul clasic?

Spagetti code

În momentul procesării unei pagini ASP, motorul de scripting de pe se activează și se dezactivează de mai multe ori pentru a gestiona chiar și o singură cerere. Acest lucru crește cantitatea de timp necesară pentru a procesa întreaga pagină și a o trimite la client. Mai mult, paginile web scrise în acest stil pot atinge ușor dimensiuni dificil de stăpânit.

Indiferent ce abordare se folosește, codul devine încurcat, lung și greu de depanat. În ASP.NET, aceste probleme sunt reduse ca posibilitate de apariție. Paginile web sunt scrise folosind conceptele programării orientate pe obiecte tradiționale.

Paginile de web ASP.NET se regăsesc controale, ce pot fi programate în mod similar cu aplicațiile desktop.Nu mai este nevoie de combinarea unui set de marcaje HTML și cod inline. Dacă se optează pentru abordarea code behind atunci când se crează paginile ASP.NET, codul și marcajul sunt plasate în doua fișiere diferite, ceea ce simplifica întreținerea codului și permite separarea sarcinii de design a paginii web de cea destul de dificilă a programării.

16Common Language Runtime – responsabil pentru executarea programelor .NET17Programe pentru calculator care au drepturi de autor înregistrare și sunt accesibile pentru a fi utilizate gratuit

Limbajele de scriptare

La început, ASP părea o solutie perfectă pentru dezvoltatorii de aplicații desktop care vroiau să treacă la dezvoltare web,fără să necesite învațarea unui limbaj de programare cu totul nou,aceștia putând să foloseăscă limbaje familiare cum ar fi VBScript. Folosind deja popularul COM18 ca o coloană vertebrală, aceste limbaje au acționat ca un vehicul pentru accesarea componentelor și resurselor de pe server. Deși ASP era ușor de înțeles pentru dezvoltatorii obișnuiți cu limbaje precum VBScript, aceasta a ridicat o altă problema, ASP fiind bazat pe tehnologii vechi, ce au fost inițial create pentru aplicații desktop, acestea nu au putut să funcționeze la fel de bine în noul mediu de dezvoltare web.

O altă problemă este faptul că pentru fiecare obiect sau variabilă utilizată în ASP clasic era creată ca un tip de dată variant. Un tip de data variant este slab tipizat, având nevoie de cantitați mari de memorie, iar tipul exact este cunoscut doar la momentul rulării, de aici rezultând că au performanțe mult mai slabe decât variabilele explicite. De asemenea, cu acest tip de variabile era imposibil de creat un IDE care să ofere facilități de debugging, IntelliSense (recunoașterea elementelor lexicale) și verificarea erorilor.

Ce aduce ASP.NET?

Sunt o serie diferențe majore între ASP.NET și platformele de dezvoltare existente:

ASP.NET aduce modelul de programare în întregime obiect-orientat, având o arhitectură bazată pe evenimente și controale, care încurajează încapsularea și refolosirea codului;

ASP.NET oferă posibilitatea de a programa în orice limbaj acceptat de.NET;

ASP.NET sprijină ideea de executare rapidă: în loc de a fi interpretate de fiecare dată când acestea sunt utilizate, paginile și componentele ASP.NET sunt compilate (fie la prima cerere, fie la instalarea site-ului pe server);

modul de programare este orientat pe obiecte; orice pagină este văzută ca un obiect, derivat din clasa pusă la dispoziție de .NET Framework;

deși protocolul de comunicare HTTP este fără stare, are un mecanism încorporat care permite păstrarea stării;

ASP.NET permite dezoltarea de aplicații web bazate pe evenimente, la fel ca în cazul aplicațiilor de tip forme Windows;

este senzitiv la browserul pentru care se face trimiterea codului HTML, alegând automat codul optimizat pentru o colecție de browsere;

18 Component Object Model – folosit pentru a permite comunicarea între procese și crearea de obiecte dinamice în foarte multe limbaje de programare

ASP.NET este găzduit de către CLR; aceasta aduce beneficii notabile precum: managementul automat al memoriei prin garbage collection19; tipuri de date sigure, verificabile; manipularea structurată a erorilor; fire de execuție -pentru fiecare cerere făcută de către un client, se lansează un fir de execuție separat;

este ușor de distribuit și configurat.

Tipuri de fi iere în ASP.NETș

Într–o aplicație web sunt disponibile următoarele tipuri de fișiere:

fișiere cu extensia aspx -- pagini web asp.net, ele conțin interfața utilizator și opțional cod (JavaScript, C#);

fișiere cu extensia ascx -- controale utilizator ASP.NET; reprezintă controale personalizate, dezvoltate de programatori, prin care se extinde paleta de controale cu care vine ASP.NET; aceste controale pot fi adăugate în pagini aspx;

fișiere cu extensia asmx sau svc -- servicii web ASP.NET (prima extensie) sau servicii implementate prin WCF20;

web.config – fișier de configurare a aplicației Web pentru ASP.NET; conține stringuri de conexiune către baza de date, configurări ale securității etc;

global.asax -- fișier global al aplicației; se folosește pentru a implementa cod de reacție la evenimente ale aplicației, precum pornirea sau oprirea ei;

fișiere cu extensia cs -- (în cazul ASP.NET cu C#), este partea de “code–behind” care prelucrează pe server evenimentele survenite pe partea de browser și ciclul de viață al paginilor.Astfel se obține separarea părții de interfață utilizator de cea de cod executat pe server;

fișiere cu extensia ashx -- HTTP handlers, pentru returnarea de conținut care să nu fie pagina web;

fișiere cu extensia axd -- folosite pentru urmărirea aplicației (tracing); fișiere cu extensia master -- pentru master pages; fișiere cu extensia resx -- pentru internaționalizarea și localizarea aplicațiilor

ASP.NET; fișiere cu extensia sitemap -- pentru crearea structurii site-ului; fișiere cu extensia skin -- pentru crearea de teme (“skin–uri”).

Modelul de cod

19 O forma automată de gestiune a memoriei20 Windows Communication Foundation – o parte a .NET Framework care oferă model de programare pentru construirea rapidă de aplicații

O pagină web aspx este compusă din cod ASP.NET de forma: cod HTML; acesta este interpretat de către browser; controale web; acestea se recunosc prin tagurile care încep cu prefixul

asp.Controalele web sunt procesate pe server și vor produce cod HTML care este inteligibil pentru un browser;

cod C# sau VB.NET.

Acest ultim cod este executat pe server (deci browserul nu trebuie să aibe niciun tip de suport pentru executarea de cod .NET); în funcție de locația în care se poate pune acest cod, avem posibilitățile:

cod inline, adică este scris în interiorul paginii aspx; utilizat pentru pagini web simple;

cod “în spate”, într-un document separat cu extensia cs (dacă este cod C#). Este modelul preferat pentru dezvoltarea de pagini.

Alegerea între aceste două modalități este posibilă la crearea unei noi pagini web, prin checkbox-ul “Place code in separate file”.

Browserul va primi același cod, deoarece interpretarea parții de C# și ASP.NET se face de către server. Este indicată folosirea de variante de code-behind, deoarece asta permite separarea părții de layout (ce este în sarcina unui designer) de cea de cod (sarcina de programator). În restul lucrării ne vom referi doar la modelul de code–behind.

Conectarea dintre pagina aspx și code–behind se face prin intermediul directivei Page de pe primul rând. Se specifică unde se află pagina de code–behind (atributul CodeFile); de asemenea faptul că pagina aspx este de fapt un obiect, derivat din clasa care conține code-behind (atributul Inherits). Controalele declarate în pagina aspx vor fi create automat, într-o clasă parțială, care completează în mod transparent codul din fișier.

Controale Web i controale HTMLș

Un control Web reprezintă o clasă (exemplu: System.Web.UI.WebControls.Label) ce poate fi utilizată în partea de code–behind; are un aspect vizual, generandu–se cod HTML de către server, cod care poate fi interpretat de browser; are de asemenea aspect comportamental,evenimente, și proprietăți – de exemplu un obiect de tip Label poate să suporte modificări prin lațime, text, culoare, vizibilitate. Avantajul acestor controale este că permit generarea de cod HTML complex, fără ca programatorul să fie interesat de detalii.

Astfel, se creeaza programatorului senzația că modul de dezvoltare al aplicațiilor web este foarte asemănător cu cel folosit pentru aplicațiile de tip Windows Forms, unde există o abundență de controale.

De exemplul <asp:Label...> dacă conține atributul runat cu valoarea server care este mandatoriu (ca prezența și valoare) pentru controalele web. Valoarea atributului id reprezintă numele variabilei cu care se acceseaza controlul pe parte de server.

La cealaltă extremă se află codul HTML simplu, care este direct interpretat de către browser. Problema cu acest cod este că nu poate fi accesat de către code behind.

Pentru a se permite accesarea programatică, s–a introdus conceptul de control HTML, acesta se obține din codul HTML prin adăugarea a două atribute: runat cu valoarea server și Id având drept valoare un nume de variabilă, iar accesarea controlului se face prin value sau text.

Postback

Un utilizator cere prin browser o pagină. Serverul IIS primește cererea, determină faptul ca este o pagină aspx și invocă motorul ASP.NET pentru a o executa. Motorul creează pagina și controalele conținute, se execută codul de inițializare. Pagina este creată ca șir de caractere HTML și returnată clientului. Obiectul pagină și controalele incluse sunt distruse .

O dată pagina trimisă către browser, este rândul utilizatorului să producă acțiunea de trimitere înapoi a paginii, acest lucru se realizeaza prin apăsarea unui buton, selectarea unui obiect dintr-un dropdownlist si altele.

Formularul din pagină este trimis înapoi la server, către pagina de tip.aspx. Motorul ASP.NET primește din nou cererea și recreează pagina (pagina anterioară a fost dealocată) de pe server; această refacere va restabili valorile controalelor la starea anterioară, prin mecansimul de viewstate.

ASP.NET determină care a fost acțiunea care a determinat trimiterea înapoi și execută event handlerele .Un asemenea event handler execută o operație de modificare a conținutului formei web, eventual apelând la cod pentru extragere de date de pe un server de baze de date.

Pagina .aspx cu coținutul astfel modificat este transformată în cod HTML și trimisă serverului. Obiectele folosite pentru crearea acestui răspuns sunt disponibilizate. Ciclul se reia de la pasul 2.

Postback-ul este disponbil doar pentru controale web,iar pentru a determina pe parte de code behind dacă cererea e postback sau nu, se poate folosi proprietatea de tip boolean Page.IsPostBack; aceasta are valoarea true dacă este un postback, false altfel. Mecanismul este util pentru că de regulă la postback se face umplerea controalelor cu valori dintr-o sursă de date.

Menținerea stării prin Viewstate

Viewstate este mecansimul prin care se pastrează ultima valoare a unui control. Pentru fiecare web control se poate seta valoarea EnableViewState la true (de fapt, valoarea implicită), prin asta semnalându–se ca se va menține starea. Menținerea se face prin intermediul unui câmp ascuns numit __VIEWSTATE în cod HTML și accesat cu variabila ViewState pe parte de code behind.

Stochează datele în interiorul paginii curente, sub forma unui câmp ascuns. La orice trimitere de formular către server, acest câmp este proiectat înapoi. Este de regula folosit pentru a stoca ultima valoare a unui control (si se include aici și setare privind stilul controlului, nu doar conținutul); poate fi de asemenea îmbogățit cu perechi de forma “cheie–valoare”, care ulterior pot fi modificate sau șterse.

În absența mecanismului de Viewstate, la fiecare postback s-ar reface pagina la starea inițiala, pierzându-se valorile depuse anterior în controale. De exemplu, dacă la procesarea anterioară s–a setat conținutul unei etichete la o anumită valoare, la a treia cerere aceasta valoare s–ar pierde. Acest lucru se explică, deoarece HTTP este protocol fără stare, iar serverul nu menține de la o cerere la alta valorile actuale ale controalelor. De regulă, asemenea efect este nedorit.

Eliberarea resurselor necesitate de către server pentru procesarea paginii pot fi eliberate fără problem, însă apare cazul unui câmp ascuns care va fi plimbat permanent între client și server, ceea ce duce la îngreunarea comunicării (pagină mai mare duce la o trimitere trimitere mai lentă). De regulă, pentru o pagină Web se folosesc o mulțime de controale, care implicit au partea de viewstate neinhibată, deci se poate ajunge la dimensiuni mari pentru câmpul ascuns.

Pentru contracararea acestui effect, sunt controale a căror stare nu se schimbă în timp (e.g. butoane), sau a căror stare este refăcută de fiecare dată, pentru care dezactivarea opțiunii de viewstate poate însemna o economie importantă de spațiu. De asemenea, evitarea stabilirii valorii pentru controale prin cod (și precizarea lor la designul paginii aspx) reduce viewstate-ul.

Există chiar situații când pagina cu o dimensiune prea mare a câmpurilor ascunse sunt blocate de către proxy-uri. Pentru aceasta, viewstate–ul poate fi spart în mai multe bucăți.

Viewstate se poate folosi nu doar de către controalele din pagină, ci și de către programator, permițându–se adăugarea și regăsirea unor perechi de forma (cheie, valoare).

Ciclul de viață al unei pagini

Pașii parcurși de la primirea unei cereri pentru o formă web până la furnizarea răspunsului către client sunt:

1. inițializarea paginii - La acest pas se crează pagina ASP.NET (se instanțiaza atât clasa corespunzătoare porțiunii de code–behind, cât și cea corespunzătoare paginii aspx); controalele sunt instanțiate. Dacă pagina nu este prima data cerută de către acest browser (adică dacă este un postback), atunci se face restaurarea stării din viewstate. Aici se apelează de către framework metoda Page.Init.

2. instanțierea codului utilizator - este apelată metoda Page.Load (de regulă ea este scrisă Page_Load în code behind). Aici de regulă se scrie cod care face încărcarea datelor în pagină.

3. validarea - uneori se cere ca valorile furnizate de către utilizator în browser să satisfacă anumite cerințe. Procesul de validare (care se poate efectua și de către codul JavaScript de pe client) trebuie să fie îndeplinit pentru a se asigura că valorile cu care urmează să se lucreze au relevanță. În caz contrar, pagina se poate retrimite pentru completarea adecvată a intrărilor.

4. procesarea de evenimente - sunt executate metodele care funcționează pe post de event handler. Sunt două feluri de procesări:

• răspuns imediat, dacă este vorba de apăsare de buton sau postback automat;

• răspuns de tip schimbare: dacă s–a stabilit un event handler pentru un anumit control, dar nu s-a precizat AutoPostback=true, și în plus se detectează (prin comparative cu valorile din viewstate) că a aparut o schimbare în starea controlului, atunci se exectă acest event handler.

Procesarea evenimentelor de tip schimbare se face înainte de procesarea evenimentelor de tip răspuns imediat.

5. legarea automată la date - este vorba de controale care se leagă la surse de date. Acestea îsi pot reîmprospăta automat conținutul, după eventualele modificări / adăugări / ștergeri de date.

6. disponibilizarea de resurse - se generează pagina HTML care va fi trimisă către browser. Obiectele instanțiate pentru această cerere devin neutilizabile.

Forme Web i colecș ția de controale din pagină

O pagină reprezintă un container pentru controalele dispuse pe ea; un control poate de asemenea să fie de tip container (e.g. Panel, MultiView). Regăsirea unui control “copil” conținut se face fie prin iterarea peste colecția Controls, fie prin folosirea metodei FindControl(string id). Proprietatea și metoda amintită sunt moștenite din clasa System.Web.UI.Control, bază a tot ceea ce înseamnă controale server.

Request

Proprietatea Request reprezintă obiect de tipul System.Web.HttpRequest asociat cererii HTTP efectuate de browser. Există următoarele metode și proprietăți:

Browser – permite accesarea descrierii proprietăților browserului folosit de client (tipul, numele, versiunea, platforma, capabilități etc);

Cookies – permite accesarea cookie-urilor trimise de site către browser; Form – permite accesarea formularului și a conținutului său; QueryString – pentru accesarea parametrilor interogării făcute prin get; URL, URLReferrer – adresa curentă, respectiv adresa paginii din care s-a facut

cererea curentă; UserHostName, UserHostAddress – adresa și numele calculatorului de pe care

s–a facut interogarea; UserLanguages – lista de limbi pe care o are setată browserul clientului; utilă

pentru internaționalizare.

Response

Deși rar folosit, acest obiect, instanța a clasei System.Web.HttpResponse dă acces la câteva mecanisme, printre care:

setarea de cookie-uri ce sunt trimise spre client – via proprietatea Cookies; saltul la o pagină nouă – via metoda Redirect; în felul acesta, de pe server se

trimite un mesaj browserului prin care este instruit să ceară pagina indicată de server; se poate face redirectare la orice fel de pagină (chiar și la ună de tip htm), aflată oriunde;

determinarea stării de conectare a clientului – prin interogarea proprietății boolene IsClientConnected; dacă răspunsul este false, atunci se poate renunța la o procesare consumatoare de resurse pe partea de server;

trimiterea de conținut, altceva decât șir de caractere – via proprietatea ContentType; tipurile posibile de conținut sunt prevăzute de către specificațiile MIME type21.

lucrul direct cu fluxul de ieșire către client, prin proprietatea OutputStream.

Server

21 Este un standard care permite extinderea formatului unui string, cum ar fi: caractere în alt format decât ASCII, atașamente etc.

Obiectul Server este de tip System.Web.HttpServerUtilit, acesta dând acces la metode auxiliare pentru procesarea de cereri web. Foarte utile sunt metodele HtmlEncode și duala ei HtmlDecode. Dacă codul ASP.NET postează conținut de tip șir de caractere în pagină, este obligatoriu a se face codificarea lor conform canoanelor HTML, altfel caractere precum < sau > pot produce ravagii în pagină, ele vor fi codificate ca fiind < respectiv >.

Similar pentru substituirea corectă a caracterelor în adrese, se folosesc metodele UrlEncode și UrlDecode, iar pentru determinarea căii fizice corespunzătoare unui fișier de pe site se folosește metoda MapPath(). Pentru transferarea la o altă pagină, fără a se face redirectare prin browser (ca la Response.Redirect), se poate folosi Server.Transfer(), cu restricția ca transferul să se facă doar către pagina ASP.NET de pe același server.

Tipuri de controale server

Există două tipuri majore de controale, server HTML și cele server Web. Acestea din urma cunosc specializarile: controale “bogate”, de validare, de date, de navigare, de login, parți Web, pentru ASP.NET AJAX și de tip ASP.NET mobil.Toate controalele de tip server au ca principală trăsătură faptul că se pot procesa ca obiecte pe server, având deci un tip de date reprezentat pe platforma .NET. Clasa de bază pentru orice control este clasa System.Web.UI.Control, care e derivată de clasa System.Web.UI.WebControls.WebControl, reprezentând baza pentru controalele de tip server. Clasa Control conține și transmite derivaților proprietățile și metodele:

ClientID – proprietate ce returnează identificatorul fiecărui control din pagina HTML, putând fi utilizat în JavaScript, prin funcția document.getElementById();

Controls – proprietate care returnează o colecție de controale copil ale obiectului curent;

EnableViewState – returnează sau setează o valoare logică specifică dacă ultima stare setată pentru un control va fi sau nu salvată în ViewState proprietate a paginii, care va fi transformată în campul ascuns __VIEWSTATE;

ID – este identificatorul controlului, adică numele de variabilă cu care se poate accesa în code-behind controlul respectiv;

Page – obiectul pagină care conține controlul curent; Parent – controlul în care este copil controlul curent; Visible – proprietate cu valoare logică, specificând dacă controlul este vizibil sau

nu; DataBind() – se face popularea controlului la surse de date; FindControl() – se caută recursiv un control cu un anumit nume în controlul

curent; HasControl() – returnează true sau false, arătând dacă controlul curent are sau nu

controale copil;

Render() – se scrie codul HTML asociat controlului curent; metoda se apelează de regulă de către motorul de ASP.NET și nu direct de programator.

Controale server HTML

Sunt din trei categorii mari: controale de tip input (e.g. butoane, checkbox, casuțe de text etc), controale de tip container (formular, tabel, textarea etc) și grupul format din HtmlImage, HtmlLink, HtmlTitle. Clasa de bază este HtmlControl, iar proprietățile expuse sunt:

Attributes – proprietate care permite accesarea sau adăugarea de atribute; Disabled – returnează sau setează starea de inhibare a controlului; dacă are

valoarea true, va fi afișat pe pagină, dar cu culoare gri deschis; Style – permite accesarea sau modificarea stilurilor CSS pentru controlul curent; TagName – returnează numele controlului.

Un control de tip HtmlContainerControl reprezintă un control HTML care are atât etichetă de deschidere, cât și de închidere, cum ar fi a sau img.Pe lânga cele moștenite din HtmlControl, mai avem proprietățile:

InnerHtml – returnează sau setează textul HTML dintre etichetele de deschidere și închidere. Toate caracterele sunt lăsate așa cum se dau; facilitatea este folosită de regulă pentru includerea de conținut HTML;

InnerText – ca mai sus, cu deosebirea că textul setat suferă modificarea caracterelor care au semnificație HTML predefinită (<, >, ghilimele etc) sunt înlocuite cu codificări corespunzătoare (<, >, " etc). Clasa HtmlInputControl este folosită ca bază pentru controalele care permit interacțiunea cu utilizatorul, cum ar fi <input type="text">, <input type="submit">. Față de cele moștenite din HtmlInputControl, se mai pun la dispoziție proprietățile:

o Type – obține tipul unui obiect HtmlInputControl;

o Value – obține sau setează conținutul pentru controlul curent.

Controalele server HTML pot manipula două evenimente pe parte de server:

ServerClick – este un click procesat de partea de code-behind; ServerChange – se declanșează atunci când se modifică conținutul unui control,

putând avea stări diferite: text, checkbox și altele.

Controale Web server

Reprezintă clase din spațiul de nume System.Web.UI.WebControls, gândite pentru a extinde gama de controale HTML. Un control de tip Web server nu are doar o reprezentare grafică mai bogată, datorită unui cod bogat de HTML care se generează automat, ci și un comportament mai orientat către comunicarea cu serverul. Clasa de bază este WebControl, care expune mult mai multe proprietăți și metode decât analoagele lor de tip HTML server control.

Spre exemplu, se pune la dispoziție proprietatea Font prin care se specifică proprietățile fontului curent: corp de literă, culoare, decorare, mărime etc.

Se elimină astfel necesitatea de a ști foarte bine numele atributelor CSS și valorile lor deoarece clasele folosite sunt făcute astfel încât să furnizeze doar valorile acceptabile.

Toate controalele se declară în pagina aspx cu sintaxa <asp:numeControl>, având automat proprietatea runat cu valoarea setată pe server , mai mult, dacă atributul lipsește, se declară eroare de compilare.

Spre deosebire de controalele HTML server, fiecare control server Web dispune de metoda Focus() care poate fi utilizată pe parte de code-behind pentru a selecta acel control ca fiind cel curent.

În cazul în care pe un formular sunt dispuse mai multe butoane, este posibilă specificarea unui buton ca fiind implicit. Specificarea lui se face prin intermediul formularului, care prin atributul DefaultButton poate specifica ID-ul butonului care va fi considerat ca implicit. Dacă se folosesc panouri (<asp:Panel>), se poate specifica la nivel de panou care este butonul implicit.

Gestiunea starii în ASP.NET

Se știe că HTTP este un protocol care nu păstreaza starea,iar motorul de ASP.NET distruge obiectele pe care le-a format pentru a răspunde cererii clientului, însă sunt cazuri în care este nevoie ca între două cereri succesive o anumită informație să fie păstrată și recuperată dacă este nevoie de ea.

Managementul stării în ASP.NET se poate face cu:

1. ViewState2. Query String3. Cookie-uri4. Session5. Application6. Profilul

7. Caching

View State Query String Cookie-uri utilizator Sesiune Application

Tipuri de date premise

Tot ce e serializabil Un număr limitat de caractere

Șiruri de caractere Orice tip serializabil Orice tip .NET

Durata de viață Permanent reținut la postback-uri

Se pierde când se introduce o nouă adresă

Setat de programator Expiră dupa un Δt de la ultima accesare a serverului

Durata de viață a aplicației

Stocare Un câmp ascuns în pagină

Adresa URL din browser Memoria (RAM/HDD) a calculatorului clientului

Memoria serverului sau baza de date

Memoria serverului

Vizibilitate Pagina curenta Pagina țintă Întreaga aplicație ASP.NET

În toată aplicația în cadrul unei sesiuni

În toată aplicația, global

Securitate Ușor de citit, relativ greu de modificat, poate fi criptat

Vizibil în clar, ușor de modificat

Nesigur, poate fi modificat de utilizator

Sigur, deoarece datele nu sunt trimise la client

Foarte sigure, doarece datele nu sunt trimise la client

Perfomanță Nu afectează serverul dar poate îngreuna comunicația

Bună, deoarece datele sunt puține

Bună deoarece datelesunt puține

Sesiuni mari -> server lentStocare de cumpărături

Multe date-> server lentVariabile globale

Query String

Reprezentarea se face sub forma variabilă=valoare, iar mai multe astfel de perechi pot fi separate prin caracterul &.Există următoarele limitări ale unui query string:

Informația este limitată la șiruri de caractere, care trebuie să conțină caractere valide pentru un URL;

Informația este vizibilă pentru oricine; Pot apărea modificări neanuțate ale componentelor din QS; de exemplu, în

loc de lang se poate decide să se foloseasca doar l. lungimea maximă a acestui URL este limitată.

Este foarte important ca adresa astfel formată să conțină mereu caractere valide pentru un URL. Acest lucru se obține prin apelul metodei Server.UrlEncode.

CookiesCookie-urile utilizator reprezintă fișiere care sunt menținute de către client (browser) fie

în memoria sa (și deci disponibile doar pe durata cat browserul este deschis), fie pe harddisk (și

deci pot fi valabile la repornirea browserului). Reprezintă perechi de forma cheie–valoare, ambele de tip string. Un cookie este trimis automat de către browser serverului și apoi înapoi.

Sesiunea

Sesiunea nu este parte a HTTP-ului,însă este un concept implementat de către orice framework pentru crearea de pagini web dinamice. O sesiune este o caracteristică a unui browser, reprezintând un container de elemente structurate ca și “cheie–valoare”, unde cheia este de tip string iar valoarea orice obiect serializabil. De obicei, se menține în memoria serverului câte o sesiune, instanțiată la fiecare început de sesiune. Alternativ, se poate specifica faptul ca sesiunile să fie memorate într–o bază de date.

Fiecare sesiune este identificată de un șir de 120 de biți lungime, care se salvează de regulă într–un cookie pe browser; la orice cerere efectuată de către browser, se trimite automat și acest cookie, ceea ce permite serverului să determine care este sesiunea atașată browserului; pe partea de code behind se poate accesa conținutul sesiunii. Dacă se suspectează că clientul nu are mecansimul de cookie permis (sau browserul nu permite așa ceva), atunci se poate face codificarea acestui identificator de sesiune prin intermediul URL–ului, setare disponibilă din fișierul de configurare web.config; sau se poate folosi autodetectare, deci să se decidă automat care din variante să se aplice.

Sesiunea este pierdută într–una din următoarele situații:

utilizatorul închide browserul; aceasta duce la pierderea cookie-ului care conține indentificatorul de sesiune;

sesiunea expiră; implicit, în ASP.NET dupa 20 de minute de la ultima accesare dinspre clientul care a determinat crearea sesiunii, se dealocă automat această sesiune de către server, pentru a nu irosi resursele; valoarea de timeout se poate specifica în fișierul de configurare web.config;

dacă programatorul apelează în code behind Session.Abandon().

Dacă cineva urmarește comunicația pe rețea, poate să obțina acest cookie, și deci acces la sesiune. Pentru aceasta se poate folosi SSL22.

Application

Obiectul Application este unic pentru toată lumea, deci poate să conțina niste valori care sunt de interes general: contoare, de exemplu numărul de utilizatori curent logați sau seturi de date care nu se modifică, dicționare de traducere.

22 Secure Socket Layer – este un protocol web folosit pentru a transmite fără risc documente private prin Internet

Validatoare

În cazul formularelor, o parte considerabilă o reprezintă controalele de preluare a datelor de la utilizator. Pentru aceste date preluate un minim de reguli se cere, de obicei, să fie respectat.

De exemplu, pentru un nume de utilizator, se cere ca acesta să fie nevid; pentru o adresă de email sau un număr de telefon, acesta trebuie să aibe un anumit format.

Validarea se poate face în două locuri: pe server (la postback) sau pe client, înainte de trimiterea formularului care le conține. A doua variantă este, evident, preferată, deoarece se scutește un drum până la server, pentru ca acolo să se constate că datele sunt invalide. Am prefera deci ca în codul HTML care se trimite clientului să existe invocare de cod JavaScript care să verifice, pe cât posibil, dacă regulile de validare a datelor de intrare sunt satisfăcute.

Pentru a evita scrierea acestui cod de validare manual, s–au introdus următoarele controale de validare:

<asp:RequiredFieldValidator> - verifică dacă un câmp de intrare are conținut; <asp:RangeValidator> - determină dacă valoarea specificată într–un control de

intrare are valoarea cuprinsă între două margini precizate; <asp:CompareValidator> - verifică dacă valoarea unui control este într-o relație

anume cu altă valoare; <asp:RegularExpressionValidator> - verifică dacă valoarea unui control

satisface o anumită expresie regulată; <asp:CustomValidator> - pentru cazurile în care logica de validare nu se

regăsește printre controalele enumerate anterior; <asp:ValidationSummary> - arată un sumar al erorilor de validare pentru

controalele cărora li s-a asociat validator.

Pentru un control se poate specifica mai mult de un validator; de exemplu, pentru un textbox se poate asocia un validator de tip RequiredFieldValidator care verifică dacă conținutul căsuței de text este nevid; suplimentar, se poate asocia un validator de expresie regulată, pentru a vedea dacă conținutul satisface un anumit format. Este chiar cerut a se asocia “validatorul de câmp cerut”, deoarece pentru un RegularExpressionValidator (ca de altfel și pentru RangeValidator și CompareValidator), testul de validare se consideră trecut dacă intrarea este lăsată goală. Controalele de preluare a datelor care sunt validate sunt: TextBox, ListBox, DropDownList, RadioButtonList, HtmlInputText, HtmlTextArea, HtmlSelect. când se valideaza un control de tip listă (care conține particular “List” în denumire), se validează proprietatea Value pentru obiectul ListItem curent selectat.

Pa ii de validareș

Validarea se pornește atunci când utilizatorul apasă un buton (sau link sau ImageButton) care determină trimiterea formularului către server. Fiecare componentă pomenită are o proprietate numită CausesValidation de tip boolean care dacă are valoarea true atunci se va face validarea paginii.

Validarea se face iterând peste controale și verificând dacă sunt îndeplinite condițiile specificate. Pentru validatoarele care nu sunt respectate, se retrimite pagina, cu indicarea cazurilor care nu au fost respectate. Scenariul descris corespunde situației în care în browserul folosit pentru afișare nu se permite executare de cod JavaScript; dacă se permite și validatoarele nu sunt respectate, atunci pagina nici măcar nu mai ajunge să fie trimisă către server, ci se va afișa direct mesajul de eroare pentru fiecare validator nevalidat în parte.

Clasa BaseValidator

Toate validatoarele sunt derivate din clasa BaseValidator. Proprietățile esențiale propagate în derivați sunt:

ControlToValidate – id-ul controlului pentru care se aplică validarea; este necesar a fi specificat;

Display – cum anume se afișeaza mesajul de eroare; dacă este specificată valoarea Static, atunci spațiul necesar afișării este prealocat; dacă este specificată valoarea Dynamic, atunci la afișarea acestui conținut se va produce deplasarea elementelor ce-i urmeaza pentru a face loc conținutului;

EnableClientScript – pentru valoarea true, se va permite apelarea de cod JavaScript pe client, pentru a verifica validitatea;

Enabled – specifică dacă este o validare activată sau nu; ErrorMessage – mesajul de eroare care va fi afișat într–un control

ValidationSumary, dacă există așa ceva; Text – textul de eroare care se va afișa dacă validatorul nu este respectat; ValidationGroup – se referă la posibilitatea de grupare de validatori în mai multe

grupuri.

Validatorul RequiredFieldValidator

Verifică dacă un control are sau nu conținut introdus. Implicit, se va verifica dacă textul este vid (sau conține doar spații); dacă se dorește ca această comparație să se facă cu un șir de caractere specificat de utilizator, atunci valoarea aceasta se poate da în propietatea InitialValue.

Dacă conținutul textbox-ului coincide cu această valoare inițială (dupa aplicarea unei operații de Trim pe conținutul controlului), atunci se raportează eroare de validare.

Validatorul RangeValidator

Se folosește pentru a verifica dacă o valoare specificată este într-un interval specificat prin intermediul proprietăților MinimumValue și MaximumValue;tipul de date pentru care se face comparație este specificat în proprietatea Type. Se pot specifica tipurile:

Currency Date Double Înteger String

Validatorul CompareValidator

Se folosește pentru a verifica dacă valoarea specificată într-un control este într-o relație (mai mare, mai mic etc) cu o valoare specificată, sau chiar cu valoarea unui alt control.

Prin proprietatea Operator se specifică relația pe care trebuie să o aibe controlul la care este atașată validarea. Opțiunile sunt: Equal, NotEqual, GreaterThan, GreaterThanEqual, LessThan, LessThanEqual și DataTypeCheck. Ultima valoare este utilă pentru că verifică dacă valoarea din control se poate reprezenta în tipul de date specificat via Type.

O altă situație des întâlnită este când trebuie specificat într–un textbox o valoare care să coincidă cu cea scrisă în alt textbox, de exemplu la validarea unei parole alese.Pentru aceasta, se va specifica proprietatea ControlToCompare cu referință la celălalt textbox de comparație.

Validatorul RegularExpressionValidator

Este utilizat în cazul în care se dorește specificarea unei expresii regulate față de care se face validarea. Exemplul cel mai des invocat este cel al unei adrese de email, cu reprezentarea ".*@.{2,}\..{2,}".

Controlul CustomValidator

Există situații în care validarea nu poate fi facută cu ce s–a prezentat mai sus; fie se invocă resurse de pe server (verificarea unor date din baza de date, sau logica specifică domeniului), fie este vorba de un șir de pași care definesc validarea. Pentru această situație se folosește CustomValidator. Codul se poate executa pe parte doar de server sau de server + client.

Numele funcției JavaScript care se apelează pentru validarea în browser se specifică ca valoarea a proprietății ClientValidationFunction, iar metoda din code-behind se referă cu atributul asp.net onservervalidate. Pentru ambele funcții, ca prim argument se specifică validatorul care a declanșat evenimentul de verificare, iar al doilea parametru este un argument care dă acces la valoarea controlului pentru care se face validarea, împreună cu posibilitatea de a seta validitatea stării.

Controlul ValidationSummary

Acest control nu este prevăzut pentru validare, ci pentru a strânge un sumar al erorilor din pagină. De la fiecare validator care semnalează eroare se preia conținutul proprietății ErrorMessage și se arată fie în pagină, fie într-o fereastra JavaScript, dacă proprietatea ShowMessageBox are valoarea true.

Modul de afișare a erorrilor este specificat de proprietatea DisplayMode, cu valorile: SingleParagraph, List, BulletList.

Grupuri de validare

Pentru paginile mai “stufoase”, se poate imagina o grupare a controalelor (de exemplu, prin obiecte de tip Panel). Proprietatea ValidationGroup se poate specifica la nivel de control de validare, sub forma unui șir de caractere; de asemenea, fiecare buton care produce postback poate să specifice o valoare pentru aceeași proprietate; la apasarea lui, se face verificarea validatoarelor doar pentru cele care au același grup ca și butonul acționat. Pentru toate celelate validatoare care nu fac parte din grup, se omite partea de verificare a corectitudinii.

Cascading Style Sheets

Cascading Style Sheets (CSS) reprezintă modalitatea de separare a aspectului vizual de partea de conținut; mai mult decât atât, permite centralizarea acestor reguli de stil și reutilizarea lor. Regulile CSS se referă la modul în care vor fi decorate vizual elementele HTML de către browser. Regulile sunt aplicate de către browser asupra codului HTML primit de la server.

Stilurile se aplică cu predilecție elementelor HTML, dar se pot specifica și controalelor Web server, folosind atributul CssClass.

Teme

Stilurile CSS se pot aplica ușor elementelor de tip HTML sau controalelor, dar ele vin cu un conținut fix, specific HTML-ului: dimensiunea fontului, culoarea fundalului etc.

Se pune întrebarea: cum anume se poate aplica ideea de stil și pentru proprietățile unui control ASP.NET? având în vedere ca un asemenea control poate veni cu proprietăți al căror nume nu se regăsește în ceea ce pune la dispoziție CSS–ul, avem nevoie de o modalitate de a complete facilitățile acestuia din urma. Spre exemplu ne propunem să setăm stilul unui control de tip Calendar; având în vedere ca acest control este particularizat prin proprietăți specifice claselor ASP.NET, vrem să completăm facilitățile CSS–ului.

Diferențele între stilurile CSS și temele ASP.NET sunt:

1. Temele sunt asociate controalelor, nu CSS-ului; dar temele preiau ideea de bază a CSS-ului, definirea de stil și reutilizarea lui pentru obținerea unui layout unitar.

2. Temele sunt aplicate de către server; fișierul CSS menționat pentru o pagină HTML este descărcăt de către browser și interpretat tot de către el.

3. Temele pot fi aplicate prin intermediul fișierelor de configurare; aceasta permite aplicarea unei teme paginilor dintr-un întreg folder fără a fi nevoie să se modifice paginile aspx.

4. Temele nu se aplică în aceeasi ordine ca și stilurile CSS; dacă se specifică o proprietate într–o tema și într-un control, atunci setarea din tema este cea care se aplică.

Toate temele se definesc în câte un director din directorul numit App_Themes aflat direct în rădăcina aplicației web. La un moment dat, pentru o anumită pagină cel mult o temă este activă. Pentru a defini o temă, este nevoie să se definească cel puțin un fișier text cu extensia skin. Un fișier skin conține declarații de controale ASP.NET, pentru care se pot specifica proprietățile dorite.

Spre deosebire de declarațiile asemănătoare din paginile aspx, atributul id nu se poate specifica; atributul runat trebuie să fie prezent, iar în rest orice alt atribut poate să lipsească. Se pot crea mai multe fișiere skin, de exemplu fiecare conținând declarații pentru controale înrudite. Există posibilitatea de a defini fișiere de skin și la nivel global, dar acest lucru este nerecomandat, din cauza că îngreunează instalarea aplicației pe alte servere.

Pentru a aplica o temă anume unei pagini, se poate proceda în mai multe feluri: se poate folosi atributul Theme în cadrul directivei Page, având valoarea numele directorului de tema dorit sau se poate specifica proprietatea Theme in code-behind.

Menționăm că tema se poate seta în code behind doar în evenimentul de Page_PreInit, eveniment care se declanșează înainte de Page_Load. În ambele cazuri, efectul este același.

Dacă se dorește ca un anumit control să nu fie “îmbracat” conform setărilor de temă, se poate specifica în cadrul paginii aspx atributul EnableTheming cu valoarea false.

În cadrul unui director de tip temă, se poate de asemenea crea un fișier de tip CSS. Dacă o pagină folosește tema curentă, atunci se va aplica automat și stilul CSS din directorul temei. Acest lucru este util dacă:

se dorește aplicarea de CSS pentru elemente HTML care nu corespund controalelor server;

se consideră că CSS-urile, fiind standardizate, ar trebui folosite mai mult; aceste fișiere CSS deja există și se doreăte utilizarea lor, fără a fi nevoie ca să fie

rescrise sub forma de teme.

Există o oarecare problemă: pentru a putea schimba tema la momentul rulării, deci pentru a aplica CSS-ul din directorul noii teme, este nevoie ca să se poată modifica elementul link din interiorul porțiunii de head. Modificarea se face automat dacă elementul head are precizat atributul runat cu valoarea server.

Pagini master

O pagină master este un fișier cu extensia master. Folosește un model de declarare similar cu cel al paginilor aspx, adică pagina pe care se pot depune controale și parte de code-behind. Adăugarea unei pagini master se face asemănător cu adăugarea unei pagini obișnuite de tip aspx.

Pentru crearea unei structuri unitare a unui site, se pot folosi variantele:

controale utilizator; pot fi utilizate pentru a implementa principiul “don’t repeat yourself”, dar nimeni nu poate să garanteze că acest conținut, chiar dacă e identic, este și dispus identic;

frame–uri HTML; nu mai sunt suportate de standardul XHTML; pagini master – varianta standard în ASP.NET.

O pagină master permite crearea unui șablon care va fi aplicat peste niște pagini de tip “conținut”. Utilizarea unei pagini master pentru tot site-ul determină o apariție consistentă a acestor pagini. Folosind pagini master, s–a răspuns urmatoarelor probleme:

se definește o singură dată o porțiune de pagină care poate fi reutilizată ori de câte ori se dorește;

se definesc regiunile editabile, adică acele zone în care o pagină ce folosește șablonul, are voie să adauge conținut;

suport din partea unei unelte precum Visual Studio; se permite particularizarea unor aspecte din pagina master, din pagini de conținut.

Legarea la date

Legarea la date reprezintă capacitatea unui control ASP.NET de a-și prelua conținutul din diverse surse: baze de date clasice, proprietăți, metode, servicii web etc.

După ce conținutul este preluat, e afișat conform specificului controlului. Un rol la fel de important îl au sursele de date, controale prin intermediul cărora se determină care este proveniența datelor; ele acționează ca o punte de legătura între datele afișate și controalele ASP.NET; suplimentar, mai permit și specificarea modului de manipulare a lor: datele se șterg, se adaugă, se modifică. Este remarcabilă flexibilitatea de utilizare a lor, permițând specificarea legăturii între controale și date fie exclusiv declarativ (fără sau cu foarte puțin cod pe parte de code–behind), fie prin cod, dacă se dorește personalizare.

Modul în care funcționează acest mecanism este declarativ, folosind cod scris în pagina aspx, acolo unde se precizează care e controlul de afișare. Se separă partea de code–behind de cea de specificare a sursei de date.

Există două feluri de legări de date: pentru date simple (unice) și pentru date multiple.În primul caz este vorba de controale de tip etichetă, buton, LinkButton, Image pentru care se poate specifica o singură valoare care va fi folosită.

Elemente de bază JavaScript

JavaScript permite scrierea de cod client, executat de către browser. JavaScript este văzut actualmente ca un dialect al ECMAScript; este un limbaj slab tipizat (variabilele nu îsi declară tipurile de date decât arareori), dinamic (permit modificarea codului și a tipurilor de date, în timpul execuției), interpretat. Codul JavaScript este inclus direct în documentul HTML sau referit de către acesta; el e descărcat de către browser și rulat.

Pentru a include cod JavaScript în pagina HTML, se poate proceda astfel:

se definește tratarea unui eveniment pentru un control HTML direct sub forma codului care va fi executat;

se adaugă un element <script> care conține cod JavaScript. Elementul conține cod care se execută atunci când browserul ajunge să îl încarce sau codul unei funcții care poate fi apelată direct sau indirect ca parte a procesării unui eveniment.

Acționarea de către codul JavaScript asupra componentelor din pagină se face prin HTML DOM (Document Object Model), adică DHTML. Evenimentele care pot declanșa apelul unui cod JavaScript sunt:

onchange - apare atunci când se schimbă starea unui control; onclick - apare atunci când se apasă click de mouse pe un control; onmouseover - când mouse-ul se mișcă deasupra unui control; onmouseout - când mouse-ul se mișca în afara controlului; onkeydown, onkeyup - când utilizatorul apasă/eliberează o tastă; onfocus - atunci când un control primește focusul

onload - apare atunci când o pagină se termină de încărcat; onunload - apare atunci când o pagină este pe cale de a fi descărcată din browser

(chiar dupa ce s-a dat click pe un link sau s-a introdus o nouă adresă pentru browser).

ASP.NET membership

ASP.NET pune la dispoziție un API pentru gestiunea utilizatorilor care pot să acceseze o aplicație. Se oferă suport pentru următoarele operații, care în mod normal ar trebui implementate de fiecare dată în cadrul unei aplicații web:

crearea și ștergerea de utilizatori programatic sau prin interfața pusă la dispoziție automat;

abilitatea de a reseta parole, cu posibilitatea de a trimite noua parolă prin email, dacă a fost specificată o adresă;

posibilitatea de a se crea parole în mod automat, dacă se folosește crearea programatică a utilizatorilor;

determinarea listei de utilizatori, împreună cu detaliile asociate; controale predefinite pentru logare, creare de utilizator, resetare de parolă.

Pașii ce trebuie urmați pentru utilizarea unui API-ului de membership sunt:

configurarea modului de autentificare în fișierul web.config; setarea detaliilor relativ la stocarea datelor utilizatorilor; configurarea stringului de conexiune și a furnizorului de membership; crearea de utilizatori ai aplicației web; crearea unei pagini de login.

Crearea unei pagini de login

Pagina de login se poate face cu controale puse la dispoziție de către ASP.NET sau prin pagini create de programator. Controalele ASP.NET sunt:

Login - control compus care rezolvă cele mai multe probleme legate de autentificare – afișarea unor casuțe de text în care se pot scrie numele de utilizator și parolă;

LoginStatus - exprimă starea de autentificare a unui utilizator; dacă nu e autentificat, utilizatorul va vedea un buton a cărui apăsare va duce la redirectarea către pagina de login; altfel va afișa un buton de logout;

LoginView - permite afișarea condițională a diferitelor controale; dacă utilizatorul este autentificat, atunci va vedea un anumit conținut, altfel un altul;

PasswordRecovery - permite recuperarea parolei de către utilizator;

ChangePassword - cere parola veche și permite specificarea unei noi parole; CreateUserWizard - include un wizard complex care permite crearea de conturi

utilizator.

Avantajul acestor controale este minimul de cod care trebuie scris pentru a putea face uz de partea de membership.

NHibernate

NHibernate este o soluţie(framework) open-source23 bazată pe tehnici ORM24 și un tool ce creaza o “reprezentare virtuală” a obiectelor din baza de date în cod.

Pe scurt NHibernate face toată treaba bazei de date, și utilizatorii culeg roadele. În loc să scrii sintaxe SQL sau să creezi proceduri stocate care sunt în alt loc decât codul respectiv, poți avea toate datele de acces conținute logic în aplicație. Nu doar că interogările vor fi eficiente, ele vor fi de asemenea validate de compilator, astfel dacă structura tabelelor se schimbă, compilatorul te va anunța că este nevoie de o schimbare a interogărilor.

Avantajele folosirii NHibernate

Daca nu iți place să folosești metode de scriere CRUD 25 de fiecare dată pentru fiecare parte de date de care ai nevoie, probabil ești în căutarea unei metode mai avantajoase. În acest caz ești capabil să expui un design elegant al unei baze de date.

Nu ar fi super să poți creea cateva tabele și în câteva minute, să ai un set de forme funcționale pe care să le poți folosi pentru operațiile de baza CRUD.

Un proiect de bază NHibernate este compus din 3 parți majore. Este nevoie de un fișier de mapare care să spună NHibernate cum este sau cum ar trebui să fie baza de date construită, câteva metode de acces de date care să spună NHibernate ce date să returneze sau să stocheze în baza de date, și un POCO 26 care să permită interacțiunea cu datele. Cum fișierele de mapare XML sunt cele mai folosite în proiectele NHibernate , nu sunt singurele metode de a lega date POCO .

23 Produse finite ce permit utilizatorilor să acționeze liber asupra precesului de producție sau dezvoltare24 Object Relational Mapping – un soft sau o tehnica de programare pentru convertirea datelor in limbaje de programare orientate pe obiecte25 Create, Retrieve, Update, Delete26 Plain Old CLR Object – este folosit pentru a fixa legătura CLR-ului cu .NET Framework

Prin intermediul NHibernate, acestea consistă în configurări pentru framework-ul ORM însuşi (conectarea la sursa de date, identificarea limbajului pentru date etc.) şi maparea domeniului de obiecte în tabele.

Primul lucru pe care trebuie să il facem la NHibernate este de a creea un tabel în baza de date către care să ne relaționăm tabelele. Un exemplu este un tabel de logare (Login) cu o cheie primară Id, două câmpuri nulabile prenume , nume și două câmpuri nenulabile utilizator și parolă.

Fi ierul de mapare XML hbm.xmlș

Folosind un ObjectDataSource putem mapa obiectele NHibernate direct la controalele care vor fi afișate sau cu care vor interacționa. Tot ce trebuie făcut este să creăm un ObjectDataSource care să ne returneze date din clasa de acces, să creăm un set de formuri unde să afișăm aceste date (ex: asp:GridView) și rămâne ca ASP.NET să facă munca grea pentru noi.

Tot ce trebuie scris în cod este un GridView pentru a prezenta informațiile și un OjectDataSource care să interacționeze cu clasele de date, care să furnizeze datele pentru GridView. GridView are definite câmpuri BoundField pentru toate câmpurile din tabel și de asemenea funcții de sortare și paginare. OjectDataSource are metode mapate pentru Select, Select count, Insert sau Update. Când GridView trebuie să execute una din aceste funcții, intervine OjectDataSource, care trebuie să se ocupe de aceste operații. În tandem aceste două controale (la fel ca orice alt control pentru legare de date) pot oferi o foarte simplă și rapidă interfață pentru date.

Expunerea bazei de date

Unul din cel mai important lucru pe care îl poți face într-un proiect este să iți expui datele într-un model logic și eficient. Mai departe voi prezenta fundamentele unui bun design pentru o bază de date și cum pot fi datele modelate eficient.

Voi prezenta un exemplu folosind Microsoft SQL Server Express. Cu NHibernate poți folosi aproape orice bază de date, Microsoft SQL Server Express este disponibil gratis de la Microsoft.

Un lucru foarte important care trebuie făcut de la început este de a-ți expune tabele și întreaga structură logic. Câteva minute pierdute la început realizând o baza de date logică te poate scuti de ore sau chiar zile de muncă ulterior. Vei fi surprins în mod neplăcut în momentul în care vei realiza ca ai început un proiect pe baza unei baze de date greșită.

Crearea unui model de tabele este ca o mică artă, dar nu trebuie să iți faci griji dacă nu ești un “Da Vinci”. Dacă urmezi câțiva pași de bază pentru designul unor tabele, totul va fi în regulă.

Unul din cele mai importante lucruri care trebuie făcute când faci design-ul tabelelor(modelul relațional) este acela de a le da nume sugestive. Numele tabelelor ar trebui să descrie tipurile de înregistrări care vor fi stocate în acesta. Dacă numele nu va fi schimbat, numele pe care îl vei da obiectului în baza de date va fi numele folosit în cod. Chiar dacă ar însemna să scrii mai mult pentru numele fiecărui tabel, acest lucru ar face structura tabelelor mai ușor de înțeles și eventual codul mai ușor de citit la final.

Numele tabelelor trebuie să fie singulare la fel ca și obiectele pe care le reprezintă. Fiecare rând din tabel în baza de date va reprezenta un singur obiect. Fiecare coloană din baza de date se numește câmp. Numele câmpurilor ar trebui să urmeze un tipar asemănător tabelelor, acest lucru ușurând munca utilizatorilor.

Primul câmp care este definit este cheia primară. Cheia primară a unui tabel are rolul de identificator. Definând un camp ca o cheie primară, spunem că această valoare este folosită pentru a identifica un rând unic.

O cheie primară ar trebui să aibă câteva atribute de bază:

să fie definită de tip int, long sau GUID (nu VARCHAR); să nu fie nulabil; să fie unic; să fie declarat ca cheie primară; să fie asignat de un generator POID (Persistent Object ID) NHibernate.

Una din condițiile pentru o bună cheie primară este aceea să fie asignată de un generator POID NHibernate. Asignarea automată permite NHibernate să genereze valorile pentru fiecare id și să le pună în obiectul nostru.

De fiecare dată când un obiect este adăugat în baza de date , îi este asignat un număr, fie următorul din secvență, sau un GUID27 aleator, în funcție de ce POID 28folosim.

Relaționare

Unul din obiectivele designul-ului pentru baza de date este de a reduce duplicarea datelor și de a grupa logic diferite tipuri de date în diferite tabele.

27 Globally unique identifier – este un string de 32 de caractere ce este stocat pe 128 biți.28 Este un unic identificator pentru o înregistrare dintr-un tabel, folosit ca cheie primară

Dacă dorești să ai un tabel cu anumite câmpuri cărora să nu le dai valori, avem nevoie de o metodă logică de a grupa datele în fiecare tabel și să fie relaționate la bucăți de date. Acest lucru se cheamă relaționare, și este probabil cel mai puternic concept în design-ul bazelor de date.

Permițând unui tabel să stocheze metadate sau date despre date , putem spune că un tabel A memorează date în comun cu un tabel B, dar pot fi zero sau mai multe înregistrari pentru tabelul B în tabelul A.

Sunt câteva tipuri de relaționări:

unul la mai multe mai multe la unu unu la unu mai multe la mai multe

Acestea definesc cum sunt legate datele. Relația unu la unu este mai puțin folosită putând fi modelată direct în interiorul tabelului.

Normalizarea

Normalizarea este o metodă de a construi baze de date pentru a standardiza aspectul lor și de a reduce duplicarea datelor. Din cele 6 form-uri normale, 3NF (Third Normal Form) este cel mai discutat, dar First Normal Form (1NF ) este cel de care toată lumea se îngrijorează.

Pentru a fi conform 1NF trebuie să fie eliminate coloanele ce se repetă în același tabel, și să fie create tabele separate pentru fiecare grup din datele relaționate , iar apoi fiecare rând să fie identificat prin cheia primară. Cu alte cuvinte nu este bine să salvăm date duplicate, vrem să o memorăm odată și să relaționăm la ea.

În mod esențial o bază de date 3NF va memora date în tabele multiple pentru a normaliza datele și de a reduce duplicarea, și adițional:

dependențele funcționale pe câmpuri ce nu sunt chei, sunt eliminate, fiind puse în alte tabele.; la acest nivel, câmpurile ce nu sunt chei sunt dependente de cheia primară

un rând este în 3NF dacă și numai dacă este 2NF și dacă atributele care nu contribuie la descrierea cheii primare sunt mutate într-un tabel separat

Clase

Unul din lucrurile de care vom avea nevoie pentru clase este un constructor. Constructorii sunt folosiți pentru a înnoi un obiect.

OrderHeader header = new OrderHeader();

În acest exemplu este creat un nou obiect de tipul OrderHeader. Acest obiect reprezintă tabelul OrderHeader creat în baza de date. Pentru a creea acest obiect avem nevoie de un constructor(în acest caz constructorul implicit). Constructorul implicit este pur și simplu o metodă care nu are obiecte de retunare definite, cu același nume ca, clasa noastră (în C#).

Proprietăți publice și variabile private

NHibernate trebuie să aibe un loc unde să țină datele pe care le stocăm în baza de date. Pentru ca NHibernate să își facă datoria trebuie să creăm niște proprietăți publice care să conțină datele.

O proprietate este simpla metodă prin care setăm și obținem valorile. Definim o proprietate declarând o variabilă privată care să țină actualele date și combinațiile de get și set care să manipuleze valorile în variabila privată.

private int _id;public int Id{ get { return _id; } set { _id = value; }}

Este posibil să creăm o proprietate ReadOnly unde un utilizator să nu aibe acces la un setter, aceasta fiind singura metodă de a manipula variabila privată din interiorul clasei. O proprietate ReadOnly va arăta foarte similar cu o proprietate, cu un getter standard și un setter.

Cum nu putem pune valorea NULL pentru tipul int de exemplu, putem pune o referință sau un tip generic.

Decât să folosim o valoare de tip int în C#, vom folosi un int nulabil (“int?”).

Proprietăți pentru chei străine

NHibernate ușurează munca pentru maparea cheilor străine. Trebuie doar să mapăm câmpurile ca obiecte, iar fiecare câmp să fie un link către alt tabel și le putem vedea astfel ca obiecte relaționate.

OrderHeader order = OrderHeaderDataControl.GetById(1);foreach (OrderItem item in order.OrderItems){…}

Dupa cum se obervă avem order, și ne putem uita în toate OrderItems doar accesând proprietatea OrderItems de pe obiectul OrderHeader. Acest lucru se definește ca orice altă proprietate, vom creea o variabilă privată și o proprietate publică. Tipul pe care îl asignăm proprietății va fi o altă clasă, care va avea ca rol să reprezinte celelalte elemente. Deoarece cheia străină poate fi una la mai multe , mai multe la mai multe sau oricare alta, vom folosi o listă generică de obiecte pentru a ține colecțiile.

De obicei se folosește interfața generică IList pentru a grupa obiecte, deoarece le putem casta în orice altă colecție care are IList implementată ca o listă pentru a obține o filtrare sau sortare.

Maparea datelor

Simplu spus, spunem NHibernate despre baza de date pe care am creato, cum sunt câmpurile și tabelele legate. Trebuie să spunem NHibernate de asemenea cum asignam cheile primare și tipurile de date pe care le vom folosi pentru a reprezenta datele, în ce variabile le vom stoca și asa mai departe.

Sunt două metode de bază pentru a mapa date în NHibernate, bine cunoscuta mapare XML într-un fișier hbm.xml și mai nou stilul Fluent NHibernate, care este similar paternului de interfață introdus cu frameworkul 3.5 .NET.

În ambele cazuri se crează un document pentru fiecare din tabele. Se va mapa fiecare câmp din baza de date la proprietatea care a fost creată pentru a le reprezenta în clase.

Maparea XML

Maparea XML este cu siguranța cea mai comună metodă de mapare a entităților cu NHibernate. Are la bază un document XML care conține toate informațiile despre clasele noastre și cum vor fi mapate la tabelele din baza de date.

Aceste documente au o serie de avantaje:

sunt fișiere text, deci sunt foarte mici sunt ușor de citit au un numar mic de taguri pentru a descrie datele

Cele mai mari probleme în legătură cu maparea XML este poliloghia textului și faptul că nu este compilat.

Acest lucru poate fi rezolvat limitând numărul de date pe care le punem în document. Este un număr de parametrii opțional care nu sunt neapărat necesari pentru a fi mapați, dar care pot oferi informații adiționale despre baza de date. Fără compilare când baza de date se schimbă sau clasele se schimbă, este dificil să detectezi erorile până când aplicația este cu adevarat executată și NHibernate încearcă să refacă structura bazei de date prin maparea claselor.

Putem mapa proprietăți pentru câmpurile din clase folosind taguri de id sau property. Aceste taguri sunt câmpuri standard în baza de date, nu chei străine.

Tagurile id și property au un patern standard și au un număr opțional de parametrii. Acest lucru se face definând proprietăți pe clasa pe care o mapează.

Unul din atributele opționale foarte folosit este atributul type. Cu acest atribut poți spune NHibernate că se folosește un tip de dată particular pentru a stoca informațiile în clasă.

Prima prorietate a claselor care trebuie mapată este proprietatea ID. Acest tag are un număr opțional de atribute ce pot fi setate, cel mai simplu mod fiind:

<id name="Id"><generator class="hilo"/></id>

Acest lucru arată NHibernate că avem o proprietate în clasa noastră numită Id care este mapată unui câmp în baza de date denumite Id, se poate folosi și metoda hilo pentru a genera o valoare pentru acest câmp.

Maparea Fluent

În timp ce maparea XML este fără discutie cea mai comună metodă de mapare, metoda fluent NHibernate începe să câștige teren. Acesta este un proiect separat față de proiectul de bază NHibernate.

Avantajele mapării fluent în daună mapării XML sunt urmatoarele:

Timpul de validare al mapării: XML nu este evaluat de compilator, așa că proprietățile din clase și alte erori în hbm.xml nu vor fi detectate până când aplicația nu este executată.

Mai puține linii de cod, verbozitatea. Mai puține repetiții: decât să repeți același XML de fiecare dată în interfața fluent sunt

expuse avantajele codului.

Fluent NHibernate oferă aceste avantaje mutând mapările din documentele xml direct în cod. Acestea sunt compilate împreună cu aplicația. Poți folosi de asemenea configurația de sistem a fluentului pentru a specifica paternurile pentru a face codul mai simplu și mai ușor de citit.

Codul este mai ușor de citit, doarece este mai scurt. Avantajele fluent sunt multe, de la cod simplu compilat până la faptul că este capabil să potrivească întreaga mapare a tabelelor într-o pagină.

Dacă ești în căutarea unei metode mai simple, pot fi folosite o serie de convenții simple când este creată baza de date. Se poate folosi AUTO PERSISTENCE MODEL pentru a mapa automat datele și nu ai nevoie să scrii nici un fel de cod de mapare. Aceasta metodă este perfectă dacă ai control asupra structuturii bazei de date. Tot ce trebuie să faci este să îți creezi tabelele , să îți creezi obiectele și să spui fluent să auto mapeze tabelele, clasele, deoarece ele au același nume.

Mai mult chiar, trebuie doar să îți creezi POCO și să folosești NHibernate să generezi baza de date și Fluent NHibernate o va mapa.

Ce este o sesiune NHibernate?

Ne imaginăm sesiunea NHibernate ca o conduită abstractă sau virtuală asupra bazei de date. S-au dus vremurile când trebuia să creăm o conexiune, să deschidem o conexiune, să pasăm conexiunea unui obiect comandă, să creăm un DataReader din obiectul comandă și așa mai departe.

Cu NHibernate se poate întreba SessionFactory pentru un obiect Session, și asta este tot. NHibernate se ocupă de toate sesiunile reale asupra bazei de date, conexiuni. Beneficiile sunt imediate, nefiind nevoie să știm complexitatea lucrurilor din spatele bazei de date la care încercăm să ne conectăm.

Session factory

Printr-o linie de cod se poate construi un obiect Session Factory din obiectul cfg care este folosit pentru a crea sesiuni:

ISessionFactory sessionFactory = cfg.BuildSessionFactory();

De fiecare dată când ai nevoie să creezi o sesiune este nevoie doar să „ceri” session factory să deschidă o sesiune pentru tine, dupa cum urmează:

ISession session = sessionFactory.OpenSession();

Adițional deschizând o sesiune, vrem să încadrăm elementele într-o tranzacție pentru a scădea baza de date ulterior. Deși pare că o tranzacție nou creată marește baza de date, în realitate baza de date deja folosește o serie de tranzacții pentru fiecare apelare pe care o facem, astfel spunându-i explicit să creeze o singură tranzacție pentru toate operațiile defapt micșoram numărul de apelări pe care le face.

Pentru a creea o tranzacție pentru sesiune, trebuie doar să spunem sesiunii să inceapă o tranzacție:

ITransaction tx = session.BeginTransaction();

Crearea unei sesiuni în NHibernate

Sesiunile în NHibernate nu sunt foarte complicate dar sunt extrem de puternice. Cu o sesiune NHibernate poți face toate operațiile CRUD cu ușurință.

ISession session = sessionFactory.OpenSession();ITransaction tx = session.BeginTransaction();Contact contact = new Contact("Joe", "Jones", "[email protected]");Address address = new Address("123 USA St", null, "MainTown", "IL", "80305");contact.Addresses = new List<Address>();contact.Addresses.Add(address);session.SaveOrUpdate(contact);tx.Commit();

Cu câteva linii de cod am creat un nou contact pe care l-am stocat în baza de date. Primele două linii crează o sesiune din session factory și încep o tranzacție.

Commit() are rolul de a închide tranzacția și de a sincroniza obiectele cu baza de date. Apelând această comandă anunțăm NHibernate că am reîmprospătat înregistrările din tranzacție și ar trebui puse în baza de date.

Sesiunea NHibernate versus sesiunea bazei de date

O sesiune NHibernate încapsulează și abstractizează sesiunea bazei de date. Când folosim NHibernate, nu trebuie să ne îngrijorăm de foarte multe operații în baza de date pentru a include operații SQL sau manipulări de sesiune. Lăsăm totul în seama session factory.

Sesiuni în ASP.NET

Datorită faptului că ASP.NET are o natură schimbătoare, managementul tradițional al sesiunii nu merge așa bine. dacă încerci să creezi o singură sesiune și să o folosești dealungul mai multor pagini, atunci este foarte dificl de gestionat.

Sunt câteva strategii ce pot fi folosite pentru a evita aceste probleme, implemetând un patern Singleton, care să stocheze sesiunea în contextul userului, sau să folosești un alt framework de exemplu NHibernate.Burrow.

Singleton este probabil cel mai ușor de implementat. Trebuie doar creată o clasă „sigilată” (toate variabilele clasei sunt declarate static) și apoi să fie creată o proprietate numită Instance. Atunci se poate crea un constructor non-static care are detaliile implementate cum ar fi proprietatea SessionFactory.

O altă strategie este să stochezi sesiunea în Context.Items folosind metodele Application_BeginRequest și Application_EndRequest în Global.asax.

Configurare

O configurare NHibernate la SQL Server are câteva probleme. Cel mai clar este faptul că stringul de conectare este hard-codat în aplicație. Dacă se dorește a fi schimbat, codul va trebui să fie recompilat.

Când aplicațiile sunt promovate prin nivele de Software Development Lifecycle (SDLC) de obicei se folosesc alte medii cu cerințe diferite pentru configurare. Este de obicei mai ușor să ai informațiile de configurare abastracte într-un fișier. O versiune separată a acestui fișier poate fi menținut pentru fiecare mediu.

Pentru o configurare sunt cinci opțiuni ce trebuie setate: ConnectionProvider, Dialect, ConnectionDriver, ConnectionString și ProxyFactoryFactoryClass. Toate aceste elemente au o proprietate numită name care este folosită pentru a seta o valoare. Aceste proprietăți vor fi setate la fel în fișierul de configurare.

Proprietatea ConnectionDriver nu este obligatorie, deoarece setând dialectul, se va ocupa de driverul de setări folosind niște valori implicite. Aceste setări oferă informații de bază către ConnectionDriver iar acesta trebuie să ruleze maparea.

Proprietatea ConnectionProvider spune NHibernate ce metodă are nevoie să folosească pentru a contrui o conexiune. Aceasta este folosită pentru a seta „NHibernate.Connection.DriverConnectionProvider”, dar alți provideri pot fi folosiți pentru a oferi întregul nume al clasei ("MyCode.MyCustomProvider, MyCodeAssy").

Proprietatea Dialect permite NHibernate să fie limbajul bazei de date . În cazul folosirii unei conexiuni cu o bază de date MS SQL Server 2008, atunci se va folosi

NHibernate.Dialect.MsSql2008Dialect .

ConnectionStringName oferă NHibernate informații cum să se conecteze la baza de date. Proprietatea ConnectionString acceptă un string care este defapt stringul de conectare în timp ce ConnectionStringName specifică o conexiune în secțiunea de conexiune din configurare.

Proprietatea ProxyFactoryFactoryClass este folosită să permita NHibernate să execute încărcări. De exemplu dacă ai o instanța pentru Ordering.OrderHeader și ii accesezi proprietatea OrderItems, NHibernate va încărca (din baza de date) toate obiectele asociate automat, fără să fie nevoie să se scrie alte interogări.

Trei fabrici de proxy de bază vin cu NHibernate :

NHibernate.ByteCode.LinFu.ProxyFactoryFactory NHibernate.ByteCode.Castle.ProxyFactoryFactory NHibernate.ByteCode.Spring.ProxyFactoryFactory

Majoritatea se mulțumesc cu LinFu, considerând că are îmbunătățiri de viteză față de Castle.

Castle DynamicProxy a fost implementarea standard NHibernate mai mulți ani dar mulți utilizatori NHibernate înca o folosesc. Acesta este folositor dacă decizi să implementezi un Active Record Pattern.

Propietatea finală care trebuie adugată în mapare este un element sau assembly 29 care conține numele assembly-ului mapat.

Abstractizarea configurațiilor

Unul din cele mai comune moduri de configurare NHibernate este să pui configurarea în fișierele web.config sau app.config ale aplicației. Alte setări pentru aplicație sunt deja stocate aici cum ar fi setările aplicației în blocul <appSettings> și stringul pentru conectarea la baza de date în blocul <connectionStrings> .

Punând informațiile de configurare în Web.config, putem consolida toate informațiile de configurare împreună și să culegem roadele unei protecții asupra acestui fișier.

Pentru a beneficia de aceste avantaje prin maparea în fișierul Web.config(App.config), trebuie să adaugi secțiunea de configurare.

29 Este un limbaj de programare în care fiecare interogare corespunde unei singure instrucțiuni pe o mașină

Metode de acces ale obiectelor

Trebuie creată o metodă Save() care se va ocupa de operațiile de creare și updatare, o metoda Delete() care să se ocupe de stergere, și câteva GetX() care să returneze date.

Pentru a implementa metode de baza Save() și Delete() trebuie făcute două lucruri:

scrierea logică a metodei punerea metodei într-o tranzacție

Tranzacția este importantă, deoarece dacă ceva merge prost și acțiunea nu poate fi completată atunci putem relua tranzacția și o putem manipula din cod.

Metoda de Save() este destul de ușoară. Creăm o tranzacție și apelăm Session.SaveOrUpdate() (lăsăm totul în seama NHibernate să se ocupe de inserări sau editări) și Commit() când tranzacția este finalizată. Dacă apare o eroare putem relua tranzacția și să vizualizăm eroarea în log.

O altă metodă foarte folositoare este Refresh(). Aceasta metodă apelează Session.Refresh() asupra unui obiect , forțând NHibernate să returneze ultimele obiecte din baza de date direct. Acest lucru este folositor dacă avem un proces extern, serviciu, sau un user care ar putea să interacționeze cu baza de date .

Alte metode foarte folosite sunt GetById() și GetAll(). Metoda GetByID() este destul de ușor de implementat deoarece NHibernate deja știe cum să iși obțina un obiect folosind un identificator unic.

public Contact GetById(int Id){ return Session.Get<Contact>(Id);}

Structura FieldNames

Unul din cele mai importante lucuri care pot fi facute este să generezi o structură FieldNames. Deși utilizatorii se plâng că înregistrările nu sunt destul de eficace, deoarece structura bazei de date se schimbă sau dacă au o eroare în cod nu vor ști momentul în care compilatorul a depistat eroarea.

criteria.Add(Restriction.Eq("FirstName", fName);

Acest exemplu nu va funcționa deoarece în baza de date numele este FirstName și nu Fname, astfel codul se va compila fără probleme, dar când va fi rulat vom obține o excepție deoarece FirstName nu există în obiectul nostru.

O metoda simplă de a evita aceasta problemă este să folosești structura FieldNames, care va mapa numele proprietăților la o structură locală unde poate fi accesată. În acest caz structura de mai sus se modifică astfel:

criteria.Add(Restriction.Eq(FieldNames.FirstName, fName);

În acest caz dacă numele nu este dat corect , compilatorul ne va afișa eroare.

Obiectul ICriteria

Cea mai bună metodă să faci interogări cu NHibernate este să folosești obiecte de tip criteria. Obiectul ICriteria este creat dintr-o sesiune folosind sintaxa Session.CreateCriteria<T>() sau Session.CreateCriteria(Of T)(). Trecând la un tip, pur și simplu spunem NHibernate ce tip de obiecte vor fi interogate:

ICriteria criteria = Session.CreateCriteria<Contact>();

care este echivalentul pentru

SELECT * FROM Contact;

Îndată ce obiectul ICriteria a fost construit, putem cu ușurință să cerem acestuia să returneze înregistrările dorite. Dacă se dorește retunarea unei liste de obiecte, în acest caz, o listă de obiecte de tip Contact, se apelează criteria.List<T>() sau criteria.List(Of T)().

IList<Contact> contacts= criteria.List<Contact>();

Dacă se dorește ca interogarea să returneze o singură înregistrare și să returneze NULL în caz contrar, se poate folosi UniqueResult<type>().

Contact contact=criteria.UniqueResult<Contact>();

Pentru a face accesul la date mai funcțional se va implementa o metodă GetAll() care returnează toate înregistrările. De asemenea se va crea și GetCountOfAll(), cu parametrii adiționali care ne va permite să folosim functionalitațile controlalelor framework-ului ASP.NET când avem rezultate mai mari.

Folosind un obiect ICriteria ne ușurează munca pentru a scrie metoda GetAll(). Tot ce trebuie să faci este un nou obiect ICriteria și să apelezi List<T>() pe ea, iar acesta va returna toate obiectele de acest tip.

Pentru a crea GetCountOfAll() , se va folosi ceva nou, și anume Projection. Pe scurt o proiecție spune: „decât să returnezi toate datele, mai bine dă-mi informațiile pe care le cer”.

Unul din cele mai comune proiecții pe care le folosim sunt Projections.RowCount() și Projections.Distinct(). Pentru a obține numărul de înregistrări pentru GetCountOfAll(), trebuie doar să creăm un obiect ICriteria, și să apelăm .SetProjection() pe ICriteria, astfel îi spunem că avem nevoie de proiecția RowCount(), și cerem rezultatul.

Metoda de GetAll() este foarte folositoare, dar dacă se dorește doar o parte din înregistrări? Pentru a face acest lucru trebuie doar să ii spunem ce înregistrare să aducă și de unde. Cu o variabilă , SortExpession, putem să îi spunem să sorteze înregistrările, și astfel paginarea și sortarea poate fi adăugate pe un control de tip gridview.

Pentru a realiza acest lucru trebuie să dăm un int pentru firstResult și să returneze un alt int pentru maxResults, și un string pentru sortExpression.

Filtrare ICriteria

Metodele GetById() și GetAll() sunt excelente, dar ele fac prea puțin. Daca nu vrem toate înregistrările, doar cele cu o anumită valoare, vom folosi în NHibernate un lucru numit Restrictions pentru a filtra colecția.

Unul din cele mai comune acțiuni de filtrare este să restricționezi setul de rezultate la o valoare particulară.

Legarea datelor

Legarea datelor este destul de simplă în ASP.NET. Adăugând câteva controale pe pagină și setând câteva proprietăți , pagina HTML poate deveni o pagină dinamică „vie”. Se pot adăuga date în baza de date și apoi să fie afișate pe pagină în orice fel se dorește.

Sunt câteva metode simple prin care se pot lega datele. La baza elementor este o sursă de date, niste elemente pe care le vom lega și un control care permite aceste date.

În mod esențial o sursă de date este o instanță sau o colecție de instanțe care va fi folosită pentru a popula controalele.

Sunt două metode comune prin care se poate seta o sursă de date pentru un control.

Prima este directa, legând datele din cod sau dintr-un alt proiect. A doua este prin a folosi un DataSourceId pentru a specifica id-ul controlului pe pagină cum ar fi un control ObjectDataSource de unde vin datele.

Datele individuale care formează sursa de date poate fi aproape orice, de la un simplu string pana la un POCO cu proprietăți și copii POCO.

Sunt mai multe controale ce permit legarea datelor, cum ar fi DataGrid, ListView, Repreater, Datalist, și chiar Textbox sau Label. Aceste controale pot fi legate în 2 metode, simplu sau printr-o legătură complexă.

Prin legătură simplă, putem lega o singură proprietate cum ar fi Image, la o proprietate a unui control Text.

Legarea complexă permite să legi una sau mai multe proprietăți ale sursei de date pentru unul sau mai multe controale. Acest lucru funcționează bine cu colecția de înregistrări, chiar dacă colecția conține o singură înregistrare.

Fiecare control are o primă metodă prin care datele se pot lega de ele, și în general vor fi împărțite în două categorii, legătură directă sau șablon. Un control legat printr-o legătura simplă folosește câmpuri individuale cum ar fi proprietățile .Text și .Value sau controale individuale cum ar fi <asp:BoundField> și <asp:ImageField> . Alte exemple sunt <asp:DropDownList> și <asp:CheckBoxList>.

Controlul <asp:DropDownList> expune proprietatea DataSource , DataTextField, și DataValueField. Setând aceste proprietăți, fie în paginile ASPX sau în cod, datele vor fi legate de control.

Când folosim un control șablon, specificăm cum ar trebui să arate pagina ASPX. Creăm un design pentru fiecare element și controlul apare atunci când este facută legătura cu datele.

Când creăm un layout , trebuie să afișăm datele în interiorul acestuia. Putem face acest lucru prin mai multe metode, dar cea mai ușoară trebuie să fie Eval(„PropertyName”). Pentru a afișa datele ce vor fi afișate trebuie doar să spui Eval() numele proprietății în sursa de date, pe care vrei să o afișezi.

Dacă se dorește modificarea formatului datelor, se pot folosi metode de formatare standard al stringurilor, string.Format().

Controlul <asp:ListView>

Unul din cele mai versatile controale trebuie să fie <asp:ListView> . Acest control are câteva proprietăți interesante și este ideal pentru legătura cu datele, special cu dynamic web world cu JavaScript și CSS. Una din aceste proprietăți este blocul <LayoutTemplate> care îți permite să precizezi un „ambalaj” pentru datele generate.

Acest lucru înseamnă să creezi un set de taguri pentru date. Acestea ar putea fi <ul>, taguri pentru <li> , un set de <div> sau taguri de tip <table>, sau orice alt cod.

Controlul <asp:ObjectDataSource>

O metodă excelentă în lucru cu date NHibernate este,legatura de date la controale prin care se populează controalele cu un <asp:ObjectDataSource>. Acest control permite să specifici ce tip de obiecte va returna controlul(DataObjectTypeName) și de ce obiecte controlul va avea nevoie să accese pentru a efectua operații CRUD (TypeName).

Controlul <asp:ObjectDataSource> are nevoie doar de 4 lucruri pentru a funcționa: Id, DataObjectTypeName (POCO), un Type Name (Data Access Object) și metoda CRUD.

Legătura directa

Cea mai ușoară (dar cea mai grea de menținut) metodă de a lega date la controale este să retunezi date din cod și să le setezi la proprietatea DataSource a controlului.

Controlul <asp:FormView> este cel mai ușor de adaugat și manipulat în aplicațiile .NET. Are ca șabloane <ItemTemplate> (doar pentru vizualizare). <InsertItemTemplate> (pentru inserare). <EditItemTemplate> (pentru editare) și <EmptyDataTemplate>.

Controale intregrate

Două controale sunt esențiale, dacă ai nevoie de securitate pe site, se vor folosii controalele <asp:Login> și <asp:LoginStatus> pentru a arăta loginul și statusul de logare pentru un user. Aceste controale împreună cu un form de autentficare oferă fundația de bază pentru securitatea în aplicațiile .NET.

Securitatea locației

O altă metodă de a avea un control asupra securității este să adaugi niște elemente de configurare în web.config. Se poate folosi <location> pentru a specifica numele directorului sau a unei pagini și apoi să folosești un bloc <authorization> pentru a controla accesul.

Elementul <location> este de obicei pus în web.config imediat după elementul </system.web> care face parte din blocul <configuration>. Controlul securității are două opțiuni majore, „allow” (permite) și „deny” (refuză). Se poate specifica de asemenea dacă se dorește ca securitatea să se asigure pentru toată lumea(*), sau dacă vor exista useri anonimi(?).

Roluri pe bază de utilizatori

Având posibilitatea de a putea folosi logarea unor user, se poate face o filtrare a datelor bazate pe accesul pe o pagină a unui user.

Folosind clasa System.Web.Security.RoleProvider se poate extinde controlul, apărând concepul de roluri.

Pentru ca rolurile să fie operaționale în NHibernate, trebuie implementată clasa System.Web.Security.RoleProvider. Clasa este special concepută pentru a permite utilizatorului să implementeze în ASP.NET modelul de roluri care i se pare lui logic.

Aceasta are aproape 15 metode și proprietăți ce pot fi suprascrise, dacă este nevoie. Defapt este nevoie să ne concentrăm doar pe o metodă ce trebuie implementată: GetRolesForUser().

Această metodă returnează o listă de stringuri continând numele, rolurile care aparțin unui utilizator.

Configurarea furnizorului

Având furnizorul scris, trebuie doar să indicăm ASP.NET cum să îl folosească. În web.config, sub blocul <membership>, se va adăuga un bloc <roleManager>.

Este suficient să furnizezi un nume și un tip, pentru ca ASP.NET să localizeze codul și se pot folosi toate controale de tip rol.

Odată ce au fost mapate clasele, se poate adăuga un rol Administrator în baza de date, și se pot adăuga utilizatori. Este foarte important să se populeze tabelul pentru roluri la logare pentru ca userii să aibe roluri.

NHibernate oferă câteva tool-uri. Fiecare produs are o prezentare de bază a codului și de asemenea o listă de cerințe pentru o operație NHibernate. Criteriile sunt următoarele:

Editarea: poate fi template-ul folosit pentru a genera codul NHibernate să fie modificat?

Clase parțiale: poate produsul să folosească clase parțiale pentru a genera Data Acces și straturile POCO?

N-nivele: poate generatorul să separe Data Access, POCO și layerele de prezentare în layere discrete și ușor de folosit?

Data Access: poate generatorul să creeze interogări de bază cum ar fi GetByID, GetALL, GetBy(index field), GetCount, și așa mai departe?

MTM: poate generatorul să mapeze corect și să gestioneze corect relaționările mai multe la mai multe?

Plugin Visual Studio: poate generatorul să fie executat din Visual Studio? Întegrarea în procesul de build: poate generatorul să fie o parte a

procesului de executare? Sursa editabilă: poate fi codul sursă modificat?

Fiecare criteriu va fi notat pe o scară de la 0 la 5 pentru fiecare produs generator de cod NHibernate, ce au ca scop ușurarea muncii, ne mai fiind nevoie să mapezi manual baza de date la POCO:

CodeSmith: unul din cele mai cunoscute generatoare de cod de pe piața este CodeSmith. Produsul a fost inițial o sursă gratis dar după cațiva ani a devenit un produs ce poate fi folosit total doar cu licență. O serie de versiuni de test se găsesc la adresa: http://www.codesmithtools.com/

nhib-gen: Este o sursă deschisă http://sourceforge.net/projects/nhib-gen , ce are incluse un set de clase ce pot fi implementatate în întreaga soluție NHibernate

AjGenesis: http://ajgenesis.codeplex.com/ , potrivit autorului generează orice text artefact, plecând de la modele și template-uri gratis

Visual NHibernate: o altă metodă prin care te poți uita la proiectul NHibernate este să folosești un modelator visual, cum ar fi Visual NHibernate http://www.slyce.com/VisualNHibernate/

MyGeneration: unul din cele mai bune coduri. Este o sursă deschisă, gratis. http://www.mygenerationsoftware.com , http://sourceforge.net/projects/mygeneration

NGen Nhibernate: sursa deschisă, http://sourceforge.net/projects/ngennhibernatec NHModeller: acest produs decuplează modelul de structură de date intr-o manieră

îndemanatică. http://nhmodeller.selfip.com/ Microsoft T4 T4 hbm2net

Editarea Clase parțiale

N-nivele

Data Access

MTM Plugin Visual Studio

Build Sursă editabilă

CodeSmith 5 5 5 3 5 5 5 0nhib-gen 5 5 5 5 5 5 5 5AjGenesis 5 4 1 0 5 2 5 5Visual Nh 5 3 4 5 5 5 0 0MyGeneration

5 3 5 0 5 0 5 5

NGen Nhibernate

4 1 4 5 0 0 0 5

NHModeller 0 5 1 0 5 2 5 0Microsoft T4 4 0 1 3 0 5 5 0

http://nhmodeller.selfip.com/

http://sourceforge.net/projects/ngennhibernatec

http://sourceforge.net/projects/mygeneration

http://www.mygenerationsoftware.com/

http://www.slyce.com/VisualNHibernate/

http://ajgenesis.codeplex.com/

http://sourceforge.net/projects/nhib-gen

http://www.codesmithtools.com/

T4 hbm2net 5 5 1 3 5 2 5 5

Conversia template-urilor CSS

De obicei se folosește master page pentru a furniza o temă constantă website-ului, Câteva concepte de bază sunt urmatoarele:

Crearea unui master page Crearea unei teme ASP.NET Mutarea informației CSS din template în temă Copierea HTML din template în master page Înlocuirea conținutului din template cu regiuni <asp:ContentPlaceHolder>

Website Aplicatie Rezervari Bilete

Documents

Transcript of Website Aplicatie Rezervari Bilete