Sql classe de classe de connexion contre le module - .NET

Question

Salutations tous.

J'ai besoin d'obtenir des opinions de personnes extérieures à mon environnement de travail pour voir si je peux obtenir un bon consensus général sur la conception du projet. Nous avons programmé une DLL de base de données pour notre département, cette DLL peut obtenir les connexions SQL, construire des DataTables, des DataSets, exécuter des commandes Sql, construire des lecteurs etc. Elle prend fondamentalement toutes les méthodes de base pour la connectivité DB et les enveloppe en une seule DLL afin que tout le monde utilise la même DLL et travaille de manière cohérente avec elle au lieu d'avoir tout le monde faisant leur propre classe de connexion. Ce qui peut devenir problématique.

Nous essayons également de pousser dans la POO, et ce faisant nous n'autorisons pas les gens à utiliser des modules. Mais dans mon esprit un module pourrait être le meilleur ajustement pour une référence d'objet pour cette DLL puisqu'elle sera partagée pendant un projet entier où nous devrons fondamentalement créer une nouvelle instance de l'objet DB. Chaque classe devrait avoir son propre objet DB, et c'est là que l'overhead entre, pourquoi s'embêter à avoir 8 objets Sql Connection différents pour chaque classe quand vous pouvez utiliser un objet partagé via un module. A moins que nous ne passions par l'héritage et que nous l'ayons au niveau de base de tous les niveaux d'héritage.

Essentiellement, y a-t-il un autre moyen auquel je ne pense pas? Je pêche juste pour quelques idées.

Merci les gars!

Answer 1

Cela n'a aucun sens d'interdire les modules comme n'étant pas orientés objet. Les modules dans VB.NET sont orientés objet. Un module est compilé en tant que type avec un constructeur privé et toutes ses méthodes et ses champs sont mis en partage (alias static en C#).

Je pense que, comme vous le laissez entendre, la question la plus importante est de savoir si votre classe de connexion à la base de données doit être un singleton (c'est-à-dire partagée) ou non. Singletons ont design issues, en particulier autour de l'enfilage. En effet, un singleton est juste une collection de variables globales, et nous savons comment cela fonctionne dans la plupart des systèmes. Aussi SqlConnection pooling est très efficace.

Habituellement, un singleton sera le mauvais choix pour l'accès aux données, mais bien sûr cela dépend de votre situation exacte.

Answer 2

Il est généralement préférable de rester à l'écart des singletons/classes/modules statiques si vous le pouvez. Je comprends le sentiment qui vous fait croire qu'il peut y avoir des raisons de performance/ressources de ne pas créer de nouveaux objets tout le temps, mais dans ces cas, ce n'est généralement pas un problème. D'abord, les objets en général sont très légers dans .NET. Plus précisément, cependant; Les objets ADO.NET que vous utiliserez ici - DbConnection, DbCommand, DbDataReader, etc, sont également très légers. Mais en plus de cela, mettre en cache et ré-utiliser DbConnection en particulier peut être une mauvaise chose; ADO.NET est configuré par défaut pour utiliser le regroupement de connexions, et donc la meilleure façon d'utiliser DbConnection est de l'ouvrir le plus tard possible et de le fermer le plus tôt possible ... puis d'en créer un nouveau pour votre prochaine commande. ADO.NET tirera ces connexions de la piscine, et tout sera très efficace.

---

Cela dit, cependant; Je pense que c'est un peu trop loin d'interdire totalement TOUS les cours/modules statiques. Il y a certainement beaucoup de bons usages pour eux.

Answer 3

Il existe différentes approches pour différents projets.Les modèles de conception de logiciels sont ciblés par rapport aux scénarios à fort volume et à la manière de les rendre évolutifs. Cela affectera la conception, où et comment ouvrir/fermer les connexions.

Mais le point qui s'applique à tous est:

simple responsiblity: le code pour ouvrir la connexion doit être dans un seul lieu. Il peut s'agir d'un module qui est une classe statique ou d'une classe dont vous créez une instance. Si vous ou vos collègues ouvrez une connexion à plus d'un endroit, alors quelque chose ne va pas. Ce type de code est déjà fait dans divers frameworks Microsoft tels que Application Blocks et plus tard avec d'autres choses.

Alors lequel est le meilleur: méthode d'aide statique ou instance de classe qui implémente la fonction? Si vous êtes un test unitaire alors statique n'est pas bon puisque vous ne pouvez pas le mock (bien que cela puisse être fait avec des outils spéciaux de moquerie tels que TypeMock ou JustMock)