Heim  >  Artikel  >  Backend-Entwicklung  >  Einführung in praktische Beispiele von ADO.NET

Einführung in praktische Beispiele von ADO.NET

零下一度
零下一度Original
2017-07-03 16:59:222278Durchsuche

Um die Vorteile von ADO.NET voll auszuschöpfen, ist es nicht nur notwendig, ein umfassendes und tiefgreifendes Verständnis des ADO.NET-Programmiermodells zu haben, sondern es ist auch sehr wichtig, Erfahrungen und Fähigkeiten in einem zusammenzufassen rechtzeitig. ADO verfügt über langjährige praktische Erfahrung und ADO.NET bietet auf dieser Grundlage umfangreichere und leistungsfähigere Tools. Das Designziel von ADO.NET besteht jedoch nicht darin, ein Plug-and-Play-Tool bereitzustellen, und es wird auch nicht integriert Alle Programmierarbeiten werden so vereinfacht, dass sie mit nur wenigen Mausklicks erledigt werden können.
ADO.NET enthält eine große Anzahl von Objekten, die verschiedene logische Einheiten im Datenzugriffsmodell darstellen, von denen die beiden Objekte Verbindung und Transaktion die wichtigsten sind. Die Funktion einer Verbindung besteht darin, einen Kanal für die Kommunikation mit der Back-End-Datenbank einzurichten. Das Erstellen eines Verbindungsobjekts muss auf einem bestimmten .NET-Datenanbieter basieren. Transaktionsobjekte können auf einem vorhandenen Verbindungsobjekt oder durch explizite Ausführung einer BEGIN TRAN SQL-Anweisung erstellt werden. Obwohl die Theorie einfach ist, gibt es tatsächlich viele unsichere Faktoren im Zusammenhang mit Verbindungen und Transaktionen, die einen entscheidenden Einfluss auf die Gesamtstabilität und Effizienz der Anwendung haben.

 Wie speichere ich die Verbindungszeichenfolge und schütze vertrauliche Informationen (z. B. Passwörter), die möglicherweise in der Verbindungszeichenfolge enthalten sind? Wie kann eine vollständige Datenzugriffsrichtlinie entworfen werden, die die Sicherheit (d. h. Authentifizierung, Autorisierung) berücksichtigt, ohne zu große Auswirkungen auf Leistung und Skalierbarkeit zu haben? Wenn Transaktionen erforderlich sind, wie können Transaktionen effizient implementiert und gesteuert werden? Automatische Transaktionen oder manuelle Transaktionen verwenden? Bei der Verwendung von ADO.NET müssen diese Aspekte sorgfältig berücksichtigt werden.

1. Verbindungszeichenfolge, Verbindungspool

Die Datenbankverbindung ist eine wichtige, begrenzte und teure Ressource, daher ist die sinnvolle Nutzung von Verbindungsobjekten die grundlegendste Voraussetzung für jede Anwendung. Die wichtigsten Punkte bei der Verwendung von Datenbankverbindungen lassen sich wie folgt zusammenfassen:

Achten Sie beim Speichern von Verbindungszeichenfolgen auf Sicherheit.
Öffnen Sie die Verbindung spät und schließen Sie die Verbindung früh.
Die Verbindungszeichenfolge ist der Schlüssel für den Zugriff auf die Datenbank. Neben der Beschreibung der Daten, auf die zugegriffen werden soll, enthält die Verbindungszeichenfolge auch einen Identitätsnachweis darüber, warum der Benutzer auf diese Daten zugreifen kann. Die Benutzerauthentifizierung ist der wichtigste Faktor bei der Bestimmung der Datenzugriffsrechte bei der Durchführung von Datenbankoperationen.

 1.1 Verbindungszeichenfolgen speichern

Derzeit weisen hartcodierte Verbindungszeichenfolgen die beste Leistung auf, da sie direkt in den Anwendungscode kompiliert werden. Allerdings beeinträchtigen hartcodierte Zeichenfolgen die Flexibilität des Programms und die Anwendung muss neu kompiliert werden, sobald sich die Verbindungszeichenfolge ändert.

Das externe Speichern der Verbindungszeichenfolge erhöht die Flexibilität auf Kosten eines zusätzlichen Overheads für den Zugriff auf die externe Zeichenfolge. In den allermeisten Fällen ist der daraus resultierende Leistungsaufwand jedoch vernachlässigbar, und Sie müssen sich wirklich um die Sicherheit kümmern. Beispielsweise könnte ein Angreifer die Verbindungszeichenfolge ändern oder stehlen. Gängige Methoden zum Speichern von Verbindungszeichenfolgen in der externen Umgebung sind: Konfigurationsdateien, UDL-Dateien, Windows-Registrierung.

.NET Framework-Konfigurationsdateien werden in Form von Nur-Text-Dateien bereitgestellt und sind leicht zugänglich. Wenn die Verbindungszeichenfolge ein Passwort enthält, stellt das Textformat den größten Nachteil dar, da das Passwort im Klartext gespeichert wird. Sie können über die Einführung einer dedizierten Verschlüsselungs-/Entschlüsselungs-Engine nachdenken, dieser Teil der Arbeit muss jedoch von den Entwicklern selbst erledigt werden.

UDL-Dateien sind Textdateien, die von OLE DB-Anbietern verwendet werden, d. h. SQL Server-Hostinganbieter unterstützen keine UDL-Dateien. UDL-Dateien weisen außerdem die gleichen Sicherheitsprobleme auf wie die vorherigen Konfigurationsdateien und bieten insgesamt nicht viele Vorteile.

Endlich kann die Windows-Registrierung als natürlich sicherer Speicherort genutzt werden. Die Registrierung ist eine Systemwissensdatenbank, die wichtige Informationen speichert. In Kombination mit Verschlüsselungstechnologie kann eine höhere Sicherheit erreicht werden. Die Hauptnachteile der Verwendung einer Registrierung sind der Aufwand bei der Bereitstellung, die Notwendigkeit, Registrierungsschlüssel zu erstellen (und möglicherweise eine Verschlüsselung durchzuführen) und Daten aus der Registrierung auszulesen. Obwohl das .NET Framework eine Reihe gekapselter Klassen bereitstellt, die die zugrunde liegende Win32-API aufrufen, stellt keine dieser Klassen Verschlüsselungsfunktionen bereit. Mit dem Tool aspnet_setreg.exe kann unter HKEY_LOCAL_MACHINE ein Registrierungsschlüssel erstellt werden, um den Benutzernamen und das Passwort zu speichern, zum Beispiel: aspnet_setreg.exe -k „SoftwareMyData“ -u:userID -p:password. Dieser Befehl verschlüsselt die angegebene Benutzer-ID und das angegebene Passwort.

 1.2 Prinzip des Verbindungspools

  Der Verbindungspool ermöglicht es uns, vorhandene Verbindungsobjekte über einen Pufferpool wiederzuverwenden, sodass nicht jedes Mal ein neues Objekt erstellt werden muss, wenn ein Verbindungsobjekt verwendet wird. Nach Verwendung des Verbindungspools kann nur eine kleine Anzahl von Verbindungsobjekten die Anforderungen einer großen Anzahl von Clients erfüllen.

Jeder Verbindungspool ist einer unabhängigen Verbindungszeichenfolge und seinem Transaktionskontext zugeordnet. Jedes Mal, wenn eine neue Verbindung geöffnet wird, versucht der Datenanbieter, die angegebene Verbindungszeichenfolge mit der Zeichenfolge des Verbindungspools abzugleichen. Wenn die Übereinstimmung fehlschlägt, erstellt der Datenanbieter eine neue Verbindung und fügt sie dem Verbindungspool hinzu. Nachdem der Verbindungspool erstellt wurde, wird er nicht abgebaut, es sei denn, der Prozess endet. Einige Leute denken, dass diese Verarbeitungsmethode die Leistung beeinträchtigt. Tatsächlich kostet es nicht viel, einen inaktiven oder leeren Verbindungspool aufrechtzuerhalten.

Nachdem der Verbindungspool erstellt wurde, erstellt das System einige Verbindungsobjekte und fügt sie dem Verbindungspool hinzu, bis die bewertete Mindestanzahl an Verbindungsobjekten erreicht ist. Zukünftig wird das System nach Bedarf Verbindungsobjekte erstellen und hinzufügen, bis die maximale Anzahl an Verbindungsobjekten erreicht ist. Wenn beim Anfordern eines Verbindungsobjekts durch das Programm kein freies Verbindungsobjekt verfügbar ist und die Anzahl der Objekte im Verbindungspool die Obergrenze erreicht hat, wird die Anforderung in die Warteschlange gestellt und sobald eine Verbindung freigegeben wird, zurück zum Pufferpool , wird es sofort zum Gebrauch herausgenommen.

Vermeiden Sie die programmgesteuerte Erstellung von Verbindungszeichenfolgen. Wenn die Verbindungszeichenfolge durch Zusammenführen mehrerer Eingabedaten erstellt wird, können Injektionsangriffe sie leicht ausnutzen. Wenn vom Benutzer eingegebene Daten verwendet werden müssen, muss eine strenge Validierung durchgeführt werden.

 1.3 Schließen der Verbindung

Wenn eine Verbindung geschlossen wird, wird das Verbindungsobjekt zur Wiederverwendung an den Verbindungspool zurückgegeben, aber die eigentliche Datenbankverbindung wird zu diesem Zeitpunkt nicht abgebaut. Wenn das Verbindungspooling deaktiviert ist, wird auch die eigentliche Datenbankverbindung geschlossen. Ein Punkt, der hier hervorgehoben werden muss, ist, dass das Verbindungsobjekt nach der Verwendung explizit geschlossen und an den Verbindungspool zurückgegeben werden sollte. Verlassen Sie sich nicht darauf, dass der Garbage Collector die Verbindung freigibt. Wenn die -Referenz des Verbindungsobjekts tatsächlich den gültigen Bereich überschreitet, wird die Verbindung nicht unbedingt geschlossen. Die Funktion des Garbage Collectors besteht darin, das in .NET gekapselte Objekt zu zerlegen, das die physische Verbindung darstellt. Dies bedeutet jedoch nicht dass die zugrunde liegende Verbindung ebenfalls geschlossen ist.

Durch Aufrufen der Close- oder Dispose-Methode kann die Verbindung wieder zum Verbindungspool freigegeben werden. Das Verbindungsobjekt wird nur dann aus dem Verbindungspool gelöscht, wenn die Lebensdauer endet oder ein schwerwiegender Fehler auftritt.

 1.4 Verbindungspooling und Sicherheit

  Wenn alle Datenzugriffsvorgänge einer Anwendung dieselbe Verbindungszeichenfolge verwenden, werden die Vorteile des Verbindungspools maximiert. Dies ist jedoch eine idealisierte Situation und kann im Widerspruch zu anderen Anforderungen der Anwendung stehen. Beispielsweise wäre es schwierig, Sicherheitskontrollen auf Datenbankebene durchzusetzen, wenn nur eine einzige Verbindungszeichenfolge verwendet würde.

Wenn andererseits jeder Benutzer seine eigene Verbindungszeichenfolge verwenden darf (d. h. für jeden Benutzer wird ein separates Datenbankkonto eingerichtet), entsteht zwangsläufig eine große Anzahl kleiner Verbindungspools Viele Verbindungen werden überhaupt nicht wiederverwendet. Herkömmlicherweise besteht die beste Lösung für diese Art von Problem darin, einen geeigneten Kompromiss zwischen den beiden Extremen zu finden. Wir können einen repräsentativen Satz öffentlicher Konten einrichten und die gespeicherte Prozedur so ändern, dass sie einen Parameter akzeptiert, der die Benutzer-ID darstellt. Die gespeicherte Prozedur führt verschiedene Vorgänge basierend auf der eingehenden Benutzer-ID aus.

2. Transaktionsmodell

Verteilte Unternehmensanwendungen sind untrennbar mit Transaktionen verbunden. Es gibt im Wesentlichen zwei Möglichkeiten, dem Datenzugriffscode Transaktionsverwaltungsfunktionen hinzuzufügen: manuell und automatisch.

Bei der manuellen Methode ist der Programmierer dafür verantwortlich, den gesamten Code zu schreiben, der den Transaktionsmechanismus konfiguriert und verwendet. Automatische (oder COM+) Transaktionen fügen .NET-Klassen deklarative Attribute hinzu, um die Transaktionsmerkmale von Laufzeitobjekten anzugeben. Der automatisierte Ansatz erleichtert die Konfiguration mehrerer Komponenten für die Ausführung innerhalb derselben Transaktion. Beide Transaktionsmethoden unterstützen lokale oder verteilte Transaktionen, aber die automatische Transaktionsmethode vereinfacht die verteilte Transaktionsverarbeitung erheblich.

Es muss beachtet werden, dass Transaktionen ein sehr kostspieliger Vorgang sind. Sie müssen also zweimal darüber nachdenken, bevor Sie sich für die Verwendung von Transaktionen entscheiden. Wenn Sie wirklich Transaktionen verwenden müssen, sollten Sie versuchen, die Granularität der Transaktionen zu reduzieren und die Sperrzeit und den Sperrumfang der Datenbank zu reduzieren. Beispielsweise muss für SQL Server eine einzelne SQL-Anweisung nicht explizit eine Transaktion deklarieren. SQL Server führt jede Anweisung automatisch als unabhängige Transaktion aus. Manuelle lokale Transaktionen sind immer viel schneller als andere Transaktionen, da kein DTC (Distributed Transaction Coordinator) erforderlich ist.

Manuelle Transaktionen und automatische Transaktionen sollten als zwei unterschiedliche und sich gegenseitig ausschließende Technologien betrachtet werden. Wenn Sie Transaktionsvorgänge für eine einzelne Datenbank ausführen möchten, geben Sie manuellen Transaktionen Vorrang. Wenn sich eine einzelne Transaktion über mehrere Remotedatenbanken erstreckt oder eine einzelne Transaktion mehrere Ressourcenmanager umfasst (z. B. eine Datenbank und einen MSMQ-Ressourcenmanager), erhalten automatische Transaktionen Priorität. Unabhängig davon sollte eine Vermischung der beiden Transaktionsmodi möglichst vermieden werden. Wenn die Leistung nicht besonders wichtig ist, sollten Sie erwägen, automatische Transaktionen auch nur für einen Datenbankvorgang zu verwenden, wodurch der Code sauberer (aber etwas langsamer) wird.

Kurz gesagt, um die Qualität des Datenbankzugriffscodes zu verbessern, müssen Sie über ein umfassendes Verständnis des ADO.NET-Objektmodells verfügen und verschiedene Techniken entsprechend der tatsächlichen Situation flexibel einsetzen. ADO.NET ist eine öffentliche API, egal ob es sich um Windows Forms-Anwendungen, ASP-Seiten oder Webdienste handelt, die jedoch nicht gleichzeitig Eingaben akzeptieren und Ergebnisse ausspucken . Eine Blackbox, aber ein Werkzeugkasten, der aus vielen Werkzeugen besteht.

Das obige ist der detaillierte Inhalt vonEinführung in praktische Beispiele von ADO.NET. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn