Introduction aux exemples pratiques d'ADO.NET

Pour tirer pleinement parti des avantages d'ADO.NET, il est non seulement nécessaire d'avoir une compréhension complète et approfondie du modèle de programmation ADO.NET, mais il est également très important de résumer l'expérience et les compétences dans un en temps opportun. ADO a de nombreuses années d'expérience pratique et ADO.NET fournit des outils plus riches et plus puissants basés sur cela. Cependant, l'objectif de conception d'ADO.NET n'est pas après tout de fournir un outil plug-and-play, et il ne s'intégrera pas. tout Le travail de programmation est simplifié dans la mesure où il peut être complété par de simples clics de souris.
ADO.NET contient un grand nombre d'objets représentant diverses entités logiques dans le modèle d'accès aux données, parmi lesquels les deux objets de connexion et de transaction sont les plus importants. La fonction d'une connexion est d'établir un canal de communication avec la base de données principale. La création d'un objet de connexion doit être basée sur un fournisseur de données .NET spécifique. Les objets de transaction peuvent être créés sur un objet de connexion existant ou en exécutant explicitement une instruction SQL BEGIN TRAN. Bien que la théorie soit simple, en réalité, il existe de nombreux facteurs incertains entourant les connexions et les transactions, et ils ont un impact crucial sur la stabilité et l'efficacité globales de l'application.

　Comment sauvegarder la chaîne de connexion et protéger les informations sensibles (telles que les mots de passe) qui peuvent être contenues dans la chaîne de connexion ? Comment concevoir une politique complète d’accès aux données qui prend en compte la sécurité (c’est-à-dire l’authentification, l’autorisation) sans trop d’impact sur les performances et l’évolutivité ? Si des transactions sont nécessaires, comment mettre en œuvre et contrôler efficacement les transactions ? Utiliser des transactions automatiques ou des transactions manuelles ? Lors de l'utilisation d'ADO.NET, ces problèmes doivent être soigneusement examinés.

1. Chaîne de connexion, pool de connexion

La connexion à la base de données est une ressource importante, limitée et coûteuse, donc faire bon usage des objets de connexion est l'exigence la plus fondamentale pour toute application. Les points clés de l'utilisation des connexions à la base de données peuvent être résumés comme suit :

Faites attention à la sécurité lors de l'enregistrement des chaînes de connexion.
Ouvrez la connexion tardivement et fermez la connexion plus tôt.
La chaîne de connexion est la clé pour accéder à la base de données. En plus de décrire les données auxquelles il faut accéder, la chaîne de connexion contient également une preuve d'identité expliquant pourquoi l'utilisateur peut accéder à ces données. L'authentification des utilisateurs est le facteur le plus important pour déterminer les droits d'accès aux données lors de l'exécution des opérations de base de données.

　1.1 Sauvegarde des chaînes de connexion

Actuellement, les chaînes de connexion codées en dur ont les meilleures performances car elles sont compilées directement dans le code de l'application. Cependant, les chaînes codées en dur affectent la flexibilité du programme et l'application doit être recompilée une fois la chaîne de connexion modifiée.

L'enregistrement de la chaîne de connexion en externe augmente la flexibilité au détriment d'une surcharge supplémentaire pour l'accès à la chaîne externe. Mais dans la grande majorité des cas, la surcharge de performances qui en résulte est négligeable, et ce dont vous devez vraiment vous soucier, c'est la sécurité. Par exemple, un attaquant peut modifier ou voler la chaîne de connexion. Les moyens courants d'enregistrer les chaînes de connexion à l'environnement externe sont : les fichiers de configuration, les fichiers UDL, le registre Windows.

Les fichiers de configuration du framework .NET sont déployés sous forme de fichiers texte brut et sont faciles d'accès. Si la chaîne de connexion contient un mot de passe, le format texte sera le plus gros inconvénient, car le mot de passe sera enregistré en texte clair. Vous pouvez envisager d’introduire un moteur de chiffrement/déchiffrement dédié, mais cette partie du travail doit être effectuée par les développeurs eux-mêmes.

Les fichiers UDL sont des fichiers texte utilisés par les fournisseurs OLE DB, c'est-à-dire que les fournisseurs d'hébergement SQL Server ne prennent pas en charge les fichiers UDL. Les fichiers UDL présentent également les mêmes problèmes de sécurité que les fichiers de configuration précédents et, dans l’ensemble, ils ne présentent pas beaucoup d’avantages.

Enfin, le registre Windows peut être utilisé comme lieu de stockage naturellement sécurisé. Le registre est une base de connaissances système qui stocke des informations clés. En combinaison avec la technologie de cryptage, une sécurité plus élevée peut être obtenue. Les principaux inconvénients de l'utilisation d'un registre sont les problèmes de déploiement, la nécessité de créer des clés de registre (et éventuellement d'effectuer un chiffrement) et de lire les données du registre. Bien que le .NET Framework fournisse un ensemble de classes encapsulées qui appellent l'API Win32 sous-jacente, aucune de ces classes ne fournit de fonctions de chiffrement. L'outil aspnet_setreg.exe peut être utilisé pour créer une clé d'enregistrement sous HKEY_LOCAL_MACHINE pour enregistrer le nom d'utilisateur et le mot de passe, par exemple : aspnet_setreg.exe -k "SoftwareMyData" -u:userID -p:password. Cette commande chiffrera l'ID utilisateur et le mot de passe spécifiés.

　1.2 Principe du pool de connexions

　 Le pool de connexions nous permet de réutiliser des objets de connexion existants via un pool de tampons, évitant ainsi d'avoir à créer un nouvel objet à chaque fois qu'un objet de connexion est utilisé. Après avoir utilisé le pool de connexions, seul un petit nombre d'objets de connexion peut répondre aux besoins d'un grand nombre de clients.

Chaque pool de connexions est associé à une chaîne de connexion indépendante et à son contexte de transaction. Chaque fois qu'une nouvelle connexion est ouverte, le fournisseur de données tente de faire correspondre la chaîne de connexion spécifiée avec la chaîne du pool de connexions. Si la correspondance échoue, le fournisseur de données crée une nouvelle connexion et l'ajoute au pool de connexions. Une fois le pool de connexions créé, il ne sera pas démantelé à moins que le processus ne soit terminé. Certaines personnes pensent que cette méthode de traitement affectera les performances. En fait, maintenir un pool de connexions inactif ou vide ne coûte pas cher.

Une fois le pool de connexions créé, le système créera des objets de connexion et les ajoutera au pool de connexions jusqu'à ce que le nombre minimum évalué d'objets de connexion soit atteint. À l'avenir, le système créera et ajoutera des objets de connexion selon les besoins jusqu'à ce que le nombre maximum d'objets de connexion soit atteint. S'il n'y a aucun objet de connexion libre disponible lorsque le programme demande un objet de connexion et que le nombre d'objets dans le pool de connexions a atteint la limite supérieure, la demande est placée dans la file d'attente et une fois qu'une connexion est libérée vers le pool de mémoire tampon , il est immédiatement retiré pour être utilisé.

Évitez de construire des chaînes de connexion par programmation. Si la chaîne de connexion est construite en fusionnant plusieurs données d’entrée, il est facile pour les attaques par injection d’en profiter. Si des données saisies par l'utilisateur doivent être utilisées, une validation stricte doit être effectuée.

　1.3 Fermeture de la connexion

Lorsqu'une connexion est fermée, l'objet de connexion est renvoyé au pool de connexions pour être réutilisé, mais la connexion à la base de données réelle n'est pas interrompue pour le moment. Si le regroupement de connexions est désactivé, la connexion à la base de données réelle est également fermée. Un point qui doit être souligné ici est que l'objet de connexion doit être explicitement fermé et renvoyé au pool de connexions après utilisation. Ne comptez pas sur le garbage collector pour libérer la connexion. En fait, lorsque la référence de l'objet de connexion dépasse la plage valide, la connexion n'est pas nécessairement fermée - la fonction du garbage collector est de démonter l'objet encapsulé .NET représentant la connexion physique, mais cela ne veut pas dire que le sous-jacent La connexion est également fermée.

L'appel de la méthode Close ou Dispose peut libérer la connexion au pool de connexions. L'objet de connexion sera supprimé du pool de connexions uniquement lorsque la durée de vie se termine ou qu'une erreur grave se produit.

　1.4 Regroupement de connexions et sécurité

　 Si toutes les opérations d'accès aux données d'une application utilisent la même chaîne de connexion, les avantages du pool de connexions seront maximisés. Cependant, il s’agit d’une situation idéalisée qui peut entrer en conflit avec d’autres exigences de la demande. Par exemple, il serait difficile d'appliquer des contrôles de sécurité au niveau de la base de données si une seule chaîne de connexion était utilisée.

D'un autre côté, si chaque utilisateur est autorisé à utiliser sa propre chaîne de connexion (c'est-à-dire qu'un compte de base de données distinct est défini pour chaque utilisateur), il y aura inévitablement un grand nombre de petits pools de connexions, et de nombreuses connexions ne seront pas du tout réutilisées. Classiquement, la meilleure solution à ce type de problème consiste à trouver un compromis approprié entre les deux extrêmes. Nous pouvons configurer un ensemble représentatif de comptes publics et modifier la procédure stockée pour accepter un paramètre représentant l'ID utilisateur. La procédure stockée effectue différentes opérations en fonction de l'ID utilisateur entrant.

2. Modèle de transaction

Les applications d'entreprise distribuées sont indissociables des transactions. Il existe deux manières principales d'ajouter des fonctions de gestion des transactions au code d'accès aux données : manuelle et automatique.

Dans la méthode manuelle, le programmeur est responsable de l'écriture de tout le code qui configure et utilise le mécanisme de transaction. Les transactions automatiques (ou COM+) ajoutent des attributs déclaratifs aux classes .NET pour spécifier les caractéristiques transactionnelles des objets d'exécution. L'approche automatisée facilite la configuration de plusieurs composants à exécuter au sein de la même transaction. Les deux méthodes de transaction prennent en charge les transactions locales ou distribuées, mais la méthode de transaction automatique simplifie grandement le traitement des transactions distribuées.

Il faut noter que les transactions sont une opération très coûteuse, il faut donc y réfléchir à deux fois avant de décider d'utiliser des transactions. Si vous avez vraiment besoin d'utiliser des transactions, vous devez essayer de réduire la granularité des transactions ainsi que le temps de verrouillage et la portée du verrouillage de la base de données. Par exemple, pour SQL Server, une seule instruction SQL n'a pas besoin de déclarer explicitement une transaction. SQL Server exécutera automatiquement chaque instruction en tant que transaction indépendante. Les transactions locales manuelles sont toujours beaucoup plus rapides que les autres transactions car elles ne nécessitent pas d'impliquer DTC (Distributed Transaction Coordination).

Les transactions manuelles et les transactions automatiques doivent être considérées comme deux technologies différentes et mutuellement exclusives. Si vous souhaitez effectuer des opérations transactionnelles sur une seule base de données, privilégiez les transactions manuelles. Lorsqu'une seule transaction s'étend sur plusieurs bases de données distantes ou qu'une seule transaction implique plusieurs gestionnaires de ressources (par exemple, une base de données et un gestionnaire de ressources MSMQ), les transactions automatiques sont prioritaires. Quoi qu’il en soit, il convient d’éviter autant que possible de mélanger les deux modes de transaction. Si les performances ne sont pas particulièrement importantes, envisagez d'utiliser des transactions automatiques même pour une seule opération de base de données, ce qui rend le code plus propre (mais légèrement plus lent).

En bref, pour améliorer la qualité du code d'accès à la base de données, vous devez avoir une compréhension approfondie du modèle objet ADO.NET et utiliser avec flexibilité diverses techniques en fonction de la situation réelle. ADO.NET est une API publique. Diverses applications, qu'il s'agisse d'applications Windows Forms, de pages ASP ou de services Web, peuvent accéder à la base de données via ADO.NET. Cependant, ADO.NET n'accepte pas les entrées et ne crache pas les résultats en même temps ; . Une boîte noire, mais une boîte à outils composée de nombreux outils.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!