Abstraction correcte du niveau de base de données dans un système à 3 niveaux?

Question

Je crée une application à 3 niveaux. Fondamentalement, il va

client -> (via le serveur facultatif à être un client léger) -> Business Logic -> Base de données couche

Et essentiellement faire en sorte qu'il n'y ait jamais de sauter autour. En tant que tel, je veux que toutes les requêtes SQL et autres soient dans le calque de base de données.

Eh bien, maintenant je suis un peu confus. J'ai fait quelques classes statiques pour commencer le niveau de base de données mais que dois-je faire pour les connexions de base de données? Devrais-je simplement créer une nouvelle connexion à la base de données à chaque fois que j'entre dans la couche de base de données ou est-ce que ce serait gaspillage? Est-ce que Connection.Open() prend du temps chaque fois que vous avez un ConnectionPool? Pour moi, il ne convient pas que le niveau Business doive transmettre un objet IdbConnection au niveau Base de données. Il semble que le niveau Base de données doit gérer tout le code spécifique à la base de données. Qu'est-ce que tu penses? Comment puis-je le faire de la bonne façon tout en restant pratique?

Answer 1

En raison de ConnectionPool, ouvrir une nouvelle connexion chaque fois que vous accédez à la base de données n'est généralement pas un problème.

Si vous pouvez réutiliser la connexion ouverte sans laisser les connexions ouvertes depuis longtemps, et sans risquer laissant orphelins les connexions ouvertes, il ne fait pas mal de réutiliser les connexions ouvertes. (J'injecte en fait un datatool dans toutes mes classes qui accèdent à la base de données, principalement pour des tests unitaires, mais cela me permet également de garder une connexion ouverte pour être utilisée par plusieurs appels au db.)

encore une fois, vous ne devriez pas trop insister sur l'ouverture/fermeture d'un grand nombre de connexions. Il est plus importante que votre DAL:

• est maintenable, simple, flexible
• performe aussi bien que possible
• (le plus important) toujours bien aliène de ses connexions.

Answer 2

N'ouvrez la connexion que lorsque vous en avez besoin. Ne pas maintenir une connexion à la base de données, ce qui est beaucoup plus coûteux. Bien sûr, votre couche db va ouvrir la connexion, je ne sais pas pourquoi vous pensez que le BLL va passer une connexion à la base de données. La BLL ne connaît pas la base de données (du moins elle ne devrait pas), elle devrait gérer les règles métier et autres. La connexion réelle est ouverte sur la couche db.

Voici un lien qui montre comment le BLL devrait ressembler à:

Validating data in .net

La chaîne de connexion elle-même devrait être simplement une variable de type chaîne privée au sein de votre classe de couche db et vous devriez être en mesure de tirer la chaîne de connexion informations à partir d'un fichier web.config.

Answer 3

Vous pouvez créer une classe (ou un espace de noms de classes, en fonction de la taille) pour héberger la couche de base de données. Dans votre classe de base de données, vous devez simplement utiliser un pool de connexions dans la couche de base de données. Le pool gardera n nombre de connexions ouvertes à la base de données à un moment donné, de sorte que vous pouvez simplement exécuter une requête en utilisant l'une des connexions regroupées sans encourir de surcharge significative. Avec ceci, votre couche de base de données devrait présenter une "API" de méthodes publiques que la couche de gestion peut appeler. Aucune de ces méthodes ne doit exposer un objet de connexion à une base de données - ces détails sont internes à la couche de données. Puis, à partir de votre couche de gestion, appelez simplement l'API de la couche de base de données chaque fois que vous avez besoin d'exécuter une requête.

Cela aide-t-il?

Answer 4

Vous pouvez créer et ouvrir une nouvelle connexion à chaque fois que vous entrez dans la couche de base de données et fermer la connexion dès que vous en avez terminé avec elle. Le serveur .Net/Sql gère assez bien le pool de connexion pour que cela fonctionne, et c'est la façon acceptée de le faire.

Vous avez également raison de ne pas transmettre votre chaîne de connexion depuis la couche de gestion. Cela devrait être un membre privé (mais configurable) de la couche de données.

Answer 5

Traditionnellement, un "Data Access Layer" séparé fournit le contexte de base de données pour récupérer et valider des données. Il existe plusieurs modèles bien connus pour cela, tels que Repository. ADO.NET implémente plusieurs autres, tels que Provider. Entity Framework et LINQ to SQL sont également de bonnes options pour encapsuler et simplifier l'isolation du niveau de données.