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

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.