> Data > ADO.NET 2.0 plus intelligent, plus rapide et plus performant.

ADO.NET 2.0 plus intelligent, plus rapide et plus performant.

Data - Par William Vaughn - Publié le 24 juin 2010
email

A l’occasion du cadre du lancement de Visual Studio 2005 et de SQL Server 2005, les fournisseurs de contenu nous inondent de cours, d’articles techniques et de documents marketing sur le sujet. Dans leur grande majorité, ces nouveaux contenus exaltent ouvertement les vertus de la nouvelle version d’ADO.NET et des outils permettant de créer des applications qui la référence.Nombreux sont les articles qui se contentent d’énumérer la longue liste de nouvelles fonctionnalités clinquantes d’ADO.NET 2.0, mais je crois que les développeurs se préoccupent plus de savoir comment ces fonctionnalités résoudront des défis de développement spécifiques. Par conséquent, cet article présente ADO.NET 2.0 en répertoriant certains problèmes importants et en expliquant comment cette nouvelle version les résout d’une manière à la fois plus intelligente, plus rapide et plus performante.

L’un des problèmes les plus déplaisants d’ADO.NET est la manière dont les fournisseurs de données gèrent (mal) le pool de connexions. Par exemple, lorsqu’une connexion « expire » dans ADO.NET 1.1, le mécanisme de mise en pool conserve l’enveloppe de cette connexion jusqu’à ce qu’une application non méfiante essaie de la réutiliser. C’est seulement à ce moment que le gestionnaire du pool (pooler) se débarrasse du « cadavre ». Toutefois, ce gestionnaire conserve d’autres connexions mortes entraînant l’échec d’autres appels Open. ADO.NET 2.0 met en oeuvre une nouvelle approche : dès qu’il trouve une connexion incorrecte, il l’élimine du pool avec toutes les autres connexions incorrectes, d’où un travail grandement simplifié pour les gestionnaires d’exceptions. Vous pouvez aussi ajouter du code forçant le vidage du pool (ou de tous les pools). ADO.NET 2.0 remplace aussi les compteurs de performance de pool de connexions. Les nouveaux compteurs semblent fonctionner (à la différence des anciens, qui étaient à l’évidence inutilisables), de sorte que vous pouvez surveiller avec plus de précision l’état de votre pool de connexions.

Lorsque vous utilisez l’IDE Visual Studio 2003 pour créer une nouvelle connexion, vous avez un choix de fournisseurs OLE DB, mais aucun fournisseur de données .NET. Pour remédier à ce problème, ADO.NET 2.0 expose une nouvelle classe DbConnectionStringBuilder afin d’aider les développeurs à créer de véritables chaînes de connexion spécifiques aux fournisseurs de données .NET. Cette possibilité d’utiliser de nouvelles API .NET Framework pour lister les fournisseurs et serveurs permet aux créateurs d’outils de réaliser plus facilement des boîtes de dialogue ConnectionString.

Certaines applications, notamment celles qui ont évolué à partir des architectures JET, essaient (sans succès) d’utiliser une seule connexion pour publier des mises à jour sur des ensembles de lignes (rowset) non entièrement remplis. Par exemple, des développeurs peuvent exécuter une instruction SELECT au moyen d’un DataReader et, lorsqu’ils parcourent les lignes, ils peuvent essayer d’exécuter une commande UPDATE via la même connexion. Indépendamment du caractère judicieux (ou peu judicieux) de cette approche, ADO.NET 2.0 et SQL Server 2005 gèrent désormais les ensembles de résultats actifs multiples ou MARS (Multiple Active Resultsets). Bien qu’il me reste à adopter cette fonctionnalité, la société Microsoft semble fière de sa création. MARS permet d’exécuter des opérations supplémentaires sur une seule connexion (avec des garde-fous). Je pense qu’il est plus sensé d’ouvrir simplement une connexion supplémentaire, mais la fonctionnalité MARS étant désactivée par défaut, le choix de l’utiliser ou non est laissé au libre arbitre des développeurs.

Téléchargez cette ressource

Guide de réponse aux incidents de cybersécurité

Guide de réponse aux incidents de cybersécurité

Le National Institute of Standards and Technology (NIST) propose un guide complet pour mettre en place un plan de réponse aux incidents de cybersécurité, nous en avons extrait et détaillé les points essentiels dans ce guide. Découvrez les 6 étapes clés d'un plan de réponse efficace aux incidents de cybersécurité.

Data - Par William Vaughn - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT