Avantages et inconvénients de l'utilisation de Singleton Pattern dans DAL

Question

J'ai demandé à utiliser le modèle singleton DAL implémenté, mais je pense qu'il est difficile de mettre en commun les connexions, utilisez des transactions ... etc.

J'aimerais connaître les avantages et les inconvénients, ainsi que le meilleur moyen de mettre en commun les connexions, car il peut y avoir plus de 500 utilisateurs simultanés pour le site que je suis en train de développer.

Le serveur de base de données est Oracle 10g.

DAL utilise la bibliothèque d'entreprise 3.1

Answer 1

Le modèle singleton convient parfaitement à un DAL - je l’utilise dans ma propre application Web d’entreprise (des centaines d’utilisateurs et plus de 2 000 méthodes dans une vingtaine de classes de singleton). Le regroupement des connexions est en effet mieux géré par ado.net et le serveur SQL lui-même. Si vous souhaitez avoir plusieurs types de serveur principal, ce n'est pas un problème. Même avec un modèle singleton, vous souhaiterez probablement une classe d'accès aux données centralisée, qui gérera les spécificités de l'appel direct à la base de données (avec des paramètres, des noms de texte / procédure, des informations d'identification / une chaîne de connexion tous passés).

Dans mon cas, chaque méthode sur une seule correspond à 1: 1 avec une procédure stockée dans ma base de données. Cela crée essentiellement un "frontal" en C #. accrocher pour chaque procédure stockée, de sorte qu'ils puissent être appelés presque comme du code C # natif, syntaxiquement. Les appels vers le DAL sont très simples. J'ai plusieurs singletons à cause du nombre massif de SP en question. Chaque SP a un préfixe, comme Development_, ou Financial_, ou Organization_ ou autre. Ensuite, j'ai une classe singleton qui correspond à chacune, comme développement, finance ou organisation. Ainsi, sp Organization_ViewData serait en C # une méthode appelée ViewData sur une classe singleton nommée Organisation.

Ce n’est bien sûr qu’une façon de le faire, mais j’ai trouvé que cela fonctionnait très bien avec plusieurs développeurs et avec une grande quantité de code au cours des six dernières années. Le principal est que la cohérence est la clé. Si un programmeur frontal recherche le nom d'une méthode sur l'un de vos courtiers en singleton, cela devrait leur indiquer exactement où elle va dans la base de données. Ainsi, en cas de problème ou si quelqu'un doit chercher dans le code pour le comprendre, il y aura moins de traçage à effectuer.

Answer 2

La meilleure pratique pour le regroupement de connexions est de ne pas l'implémenter vous-même, mais plutôt de laisser le framework ADO.NET s'en charger.

Vous pouvez définir les options de regroupement de connexions en tant que paramètres dans la chaîne de connexion. Ensuite, chaque connexion ouverte avec cette chaîne sera fournie à partir du pool de connexions implémenté et géré par la structure. Lorsque vous fermez ou supprimez OracleConnection, la connexion sous-jacente n'est pas détruite mais retourne sur le pool.

Ceci est décrit ici:      http://msdn.microsoft.com/en-us/ bibliothèque / ms254502.aspx

À propos de l'utilisation des singletons en général: je les ai utilisés pour envelopper la couche d'accès aux données, et cela a toujours bien fonctionné.

Notez que les transactions ne s'appliquent qu'à des connexions spécifiques, pas à la base de données dans son ensemble. Cela signifie que vous pouvez avoir plusieurs threads en cours d'exécution, chaque thread pouvant lire et écrire dans la base de données via des transactions indépendantes, à condition que chaque thread utilise une instance OracleConnection distincte.

Answer 3

Je ne connais pas DAL, mais le modèle singleton est un excellent moyen de rendre les données globales tout en maintenant une bonne encapsulation.

Answer 4

L’utilisation d’un singleton pour la fabrique de connexions à la base de données dans le DAL est assez courante. Il vous permet de connecter plus facilement différentes implémentations de l’usine sans changer beaucoup de code. Beaucoup de gens ne semblent pas aimer le motif de singleton, mais je pense que ça marche pour ce genre de chose.

Answer 5

Je suis un peu mal à l'aise d'utiliser des singletons dans le cas d'un DAL. Et si je veux utiliser plus d'un backend de base de données. Peut-être que je veux utiliser MsSQL pour les factures mais Active Directory pour l'authentification. Ou peut-être que je veux utiliser MySQL pour les posts sur le forum, mais PostgreSQL pour le géo-clustering (plus réaliste pour moi, heh). Les interfaces singleton peuvent rendre le test des couches de base de données beaucoup plus difficile lorsque je ne peux pas passer une connexion fictive à la base de données.

Answer 6

Je ne pense pas que vous aurez des différences de performances si vous utilisez un singleton ou non, car vous pouvez toujours avoir plusieurs threads s'exécutant sur la même méthode en même temps. Si vous vous occupez de ne pas avoir de champs internes qui seront partagés dans tous les threads, tout fonctionnera correctement.

À la fin, la classe qui gère le pool de connexions doit être thread-safe et vous finirez par créer quelques verrous pouvant affecter les performances, mais ils sont tous nécessaires. (il est créé en interne dans le framework, et vous ne pouvez pas changer son comportement de toute façon)

Si vous décidez de ne pas utiliser de singleton, assurez-vous que vos instances DAL sont légères, car cela pourrait faire une différence, mais ce n'est généralement pas le cas.

Remarque: en ce qui concerne les pools de connexions, la seule chose importante à prendre en compte est de suivre les instructions "Ouvrir tard, fermer tôt". modèle. Autrement dit, retardez autant que possible l’ouverture de la connexion et fermez-la dès que vous en avez fait tout ce dont vous avez besoin.

Après avoir créé tout le système avec cette règle magique, vous pouvez jouer avec les paramètres de la chaîne de connexion pour modifier certaines options du pool (taille initiale, taille maximale, ...)