NET Framework include propria tehnologie de acces la date - ADO.NET. Această tehnologie este format din clase gestionate care permit aplicațiilor .NET să se conecteze la o sursă de date (de obicei, o bază de date relațională), executa comenzi și gestiona date offline. ADO.NET este un mic miracol că această tehnologie vă permite să scrie mai mult sau mai puțin același cod pentru a avea acces la date - atât în aplicații web și aplicații desktop client-server, și chiar și în aplicații pentru un singur utilizator care se conectează la baza de date locală .
Aflați toate elementele de bază ale ADO.NET în cadrul aplicației client, puteți vedea în ADO.NET. Nu voi descrie aici ceea ce furnizorii si ceea ce reprezinta arhitectura de date ADO.NET, ar trebui să aveți o idee generală despre nivelurile de clase conectate - conexiune, comandă, DataReader, DataAdapter și clase de nivel autonome DataSet, DataTable, DataRow, etc. . În continuare, voi lua în considerare arhitectura ADO.NET în contextul unei aplicații web ASP.NET. Ca furnizor de date pot utiliza System.Data.SqlClient (SQL Server).
Clasa Conexiune vă permite să stabiliți conexiuni la o sursă de date cu care doriți să interacționați. Înainte de a putea face orice altceva (inclusiv extragerea, ștergerea, inserarea sau actualizarea datelor), va trebui să stabiliți o conexiune. Proprietățile cheie și metodele de conectare sunt definite de interfața IDbConnection. care implementează toate clasele de conectare.
Corzi de conectare
Când creați un obiect Connection, trebuie să furnizați un șir de conexiuni. Șirul de conexiune este o secvență de perechi de nume-valoare, separate prin punct și virgulă (;). Ordinea acestor setări, precum registrul, nu este importantă. Împreună, ele indică informațiile de bază necesare pentru a stabili o conexiune.
Cu toate că șirurile de conexiuni variază în funcție de DBMS-ul relațional și de furnizorul de date folosit, sunt necesare mai multe informații aproape întotdeauna; aceste fragmente sunt descrise mai jos:
Serverul pe care se află baza de date. În exemplele de mai jos serverul de baze de date este întotdeauna situat pe același computer ca aplicația ASP.NET, deci utilizați un pseudonim sau localhost sau numele exact al serverului (in cazul meu „\ SQLEXPRESS“) în loc de numele computerului.
Baza de date de utilizat. Voi folosi baza de date de testare Northwind, care este instalată în mod implicit cu majoritatea edițiilor SQL Server.
Modul în care baza de date efectuează autentificarea. Furnizorii de date Oracle și SQL Server oferă o alegere - să aplice anumite acreditări de autentificare sau să se conecteze ca utilizator actual al sistemului. Ultima opțiune este, de obicei, mai preferată, deoarece în acest caz nu este necesar să puneți informații despre parolă în fișierele de cod sau de configurare.
De exemplu, mai jos este șirul de conectare pentru conectarea la baza de date Northwind de pe calculatorul curent utilizând securitatea integrată (adică accesarea bazei de date în numele utilizatorului Windows curent):
Dacă utilizați un furnizor OLE DB, șirul de conectare va fi similar cu cel precedent, dar adaugă un parametru de configurare suplimentară de identificare a conducătorului auto OLE DB (Provider = MSDAORA), și să se conecteze la fișierul de bază de date Access trebuie să specificați «Provider = Microsoft.Jet.OLEDB. 4.0. "
Dacă utilizați o altă persoană decât SQL Server de baze de date, poate fi necesar să se consulte cu documentația furnizorului de date (sau de referință pentru biblioteca .NET Framework clasa) pentru a afla informații despre valorile acceptate ale șirului de conexiune. De exemplu, cele mai multe baze de date suporta configurarea conexiunii timeout, setați conexiunea timeout în câteva secunde înainte de a trebui să fie o excepție. (Pentru SQL Server implicit este de 15 secunde.)
Când creați un obiect Connection, puteți transmite un șir de conexiuni constructorului ca parametru. Alternativ, puteți seta manual valoarea proprietății ConnectionString. dacă acest lucru este făcut înainte de a încerca să deschideți o conexiune.
Nu există niciun motiv pentru a codifica greu șirul de conectare. În fișierul web.config există o secțiune
Apoi, acest șir de conexiuni este ușor de preluat prin nume din colecția WebConfigurationManager.ConnectionStrings. Presupunând că ați importat spațiul de nume System.Web.Configuration, puteți utiliza următoarea instrucțiune:
Următoarele exemple presupun că acest șir de conexiuni este adăugat la fișierul web.config.
Testarea conexiunii
După selectarea unui șir de conexiuni, gestionarea conexiunii este foarte ușoară - trebuie doar să utilizați metodele Open () și Close (). Mai mult, interfața IDbConnection este moștenită de la interfața IDisposible, care definește clasa care o implementează ca resursă. Prin urmare, atunci când utilizați clasa Connection, puteți utiliza constructul de utilizare fără a apela metoda Close () - odată ce compilatorul ajunge la sfârșitul acestei construcții, conexiunea se închide.
Următorul cod din gestionarea evenimentului Page.Load poate fi folosit pentru a testa conexiunea și a afișa starea sa în textul etichetei. Pentru ca codul să funcționeze, va trebui să importați spațiul de nume System.Data.SqlClient:
Există două excepții pentru deschiderea unei conexiuni. InvalidOperationException este generat dacă șirul de conexiune nu conține informații sau conexiunea este deja deschisă. SqlException este generat în cazul oricăror alte probleme, inclusiv o eroare de conexiune la serverul de bază de date, înregistrarea sau accesul la o bază de date specifică. Operatorul de utilizare eliberează obiectul utilizat chiar și atunci când iese din bloc ca urmare a generării unei excepții nefolosite.
Stabilirea unui grup de conexiuni
Obținerea unei conexiuni necesită un timp mic, dar vizibil. Într-o aplicație web care gestionează eficient interogările, conexiunile se vor deschide și se vor închide pe termen nedefinit - pe măsură ce sunt procesate noi cereri. În acest mediu, micul aeriu al stabilirii unei conexiuni devine foarte tangibil și limitează scalabilitatea sistemului.
O soluție la această problemă ar putea fi stabilirea unei baze de conexiuni. Un pool de conexiune este practica de stocare a unui set persistent de conexiuni deschise la o bază de date care este partajată între sesiunile care utilizează aceeași sursă de date. Acest lucru evită necesitatea de a crea și distruge în mod constant conexiuni. Piscinele de conectare din ADO.NET sunt complet transparente pentru programator, iar codul de acces la date nu va necesita modificări. Atunci când un client solicită o conexiune apelând Open (), conexiunea este serviceată direct de la piscina disponibilă, fără a o mai crea din nou. Când un client eliberează o conexiune prin apelarea Close () sau Dispose () (IDisposable), nu se închide, ci se întoarce la pool pentru a răspunde la următoarea solicitare.
ADO.NET nu conține un mecanism de conectare a conexiunilor. Cu toate acestea, majoritatea furnizorilor de date ADO.NET implementează o formă a acestui pool. Furnizori de date SQL Server și Oracle oferă propriile algoritmi eficienți pentru organizarea bazelor de conexiuni. Acești algoritmi sunt implementați complet în codul gestionat și, spre deosebire de concepțiile greșite, nu folosiți servicii COM + la nivel de întreprindere. Pentru a face conexiunea reutilizabilă în SQL Server sau Oracle, șirurile de conexiune trebuie să se potrivească exact. Dacă acestea sunt diferite, o nouă conexiune este creată în noul pool.
Bazinul de conexiuni dintre SQL Server și Oracle utilizează un mecanism de comparare a textului complet. Aceasta înseamnă că orice modificare minimă a șirului de conexiune încalcă bazinul, chiar dacă modifică pur și simplu ordinea parametrilor sau adaugă un spațiu suplimentar la sfârșit. Din acest motiv, este important să nu codificați șiruri de linii de legătură grele pe diferite pagini Web. În schimb, trebuie să salvați șirul de conectare într - un singur loc - de preferință în
În ambele furnizori de date, SQL Server și Oracle, bazele de conexiuni sunt activate și utilizate automat. Cu toate acestea, puteți utiliza, de asemenea, parametrii șirului de conexiune pentru a configura dimensiunile bazinului. Acești parametri sunt descriși în tabelul de mai jos:
Setări pentru configurarea grupului de conexiuni
Numărul maxim de conexiuni permise în bazin (implicit este de 100). Dacă se atinge dimensiunea maximă a bazinului, toate încercările ulterioare de a deschide conexiunea sunt în așteptarea lansării conexiunii. (Dacă durata de timp a Connection.Timeout expiră înainte de lansarea acestei conexiuni, apare o eroare.)
Numărul minim de conexiuni care trebuie să rămână în grup (implicit este 0). Acest număr de conexiuni va fi creat la prima deschidere a unei conexiuni, ceea ce reduce timpul de așteptare pentru primul acces
Dacă este adevărat (implicit), conexiunea este ieșită din bazinul corespunzător sau, dacă este necesar, este creată și adăugată la fondul corespunzător
Specifică intervalul de timp în secunde. Dacă conexiunea este returnată la bazin și timpul de conectare a depășit durata de viață specificată, aceasta va fi distrusă. Valoarea implicită este 0, ceea ce dezactivează acest comportament. Acest instrument este convenabil când trebuie să reutilizați un număr mare de conexiuni simultan
Următorul exemplu este un șir de conexiuni care stabilește dimensiunea minimă a bazinului:
Unii furnizori includ metode pentru curățarea piscinei de conectare. De exemplu, SqlConnection poate provoca metode statice ClearPool () și ClearAllPools (). Când ClearPool () apel furnizează SqlConnection obiect și toți compușii corespunzători sunt eliminate. ClearAllPools () șterge toate piscinele de conectare din domeniul de aplicare curent. Formal, aceste metode nu închide conexiunea, ei doar le marcați ca fiind invalid, astfel încât, la sfârșitul timeout, acestea vor fi închise în timpul purificării normale a compușilor, câteva minute mai târziu.
Această funcționalitate este rar utilizată; de obicei, numai cazul în care are sens - când se știe că piscina este plin sau conexiunea a devenit invalid (de exemplu, prin repornirea SQL Server), și aveți nevoie pentru a evita greșelile.
Bazele de conexiuni ale SQL Server și Oracle sunt întotdeauna acceptate ca parte a resurselor globale ale domeniului aplicației. Bazinele rezultate de compuși nu pot fi reutilizate între diferite aplicații Web pe același server de web sau între aplicații web și alte aplicații .NET. Din același motiv, toate conexiunile se pierd atunci când domeniul de aplicare este repornit. (Domenii de aplicare sunt repornite, din diferite motive, inclusiv schimbarea paginilor web, construirea și configurarea aplicațiilor web de fișiere Domenii de aplicare și a reînceput atingerea anumitor praguri ;. De exemplu, IIS poate reporni din domeniul de aplicație care utilizează o mulțime de memorie sau de prea multe solicitări în coadă. Ambele circumstanțe pot indica degradarea performanței domeniului de aplicație.)
Articole similare
Trimiteți-le prietenilor: