Pour encapsuler la connexion à une base de données dans des objets métier ou non?

Question

J'ai l'habitude de créer moi-même la connexion à la base de données et de contrôler manuellement sa durée de vie avec `using {} '. Par exemple:

SqlConnection sqlConnection = new SqlConnection(connectionString); 
using(sqlConnection) { 
    BusinessObject myBusinessObject = new BusinessObject(sqlConnection); 
    // do stuff with the business object 
    ... 
} 

De cette façon, il est évident et évident que j'utilise une ressource qui doit être nettoyée correctement. Cependant, cela finit par être beaucoup d'efforts répétitifs. Je suis tenté de créer la connexion Sql à l'intérieur de l'objet métier et d'implémenter IDisposable dessus. Je fermerais la connexion dans la méthode Dispose().

using(BusinessObject myBusinessObject = new BusinessObject()) { 
    // do stuff with myBusinessObject 
    ... 
} 

Le problème que je vais avoir est qu'il pourrait ne pas être si évident que l'objet métier doit être disposé à moins que vous voyez dans l'utilisation.

Comment voulez-vous les gars le faire?

Answer 1

Les objets métier doivent être raisonnablement (ou complètement) stupides par rapport à la base de données. Vous devez implémenter une sorte d'objet de couche d'accès (référentiel ou contexte de données) qui sait comment conserver vos objets métier dans la base de données et y conserver la logique de connexion plutôt que de placer le code dans chacun de vos objets métier. Votre référentiel ou contexte serait jetable afin qu'il puisse nettoyer après lui-même. @ La suggestion de Marc que vous suivez le modèle d'unité de travail est une bonne idée. Vous voudrez peut-être regarder LINQtoSQL, nHibernate, Subsonic, etc. pour les utiliser ou au moins pour avoir des idées sur la façon de structurer un bon calque de données si vous insistez pour écrire le vôtre. D'après mon expérience personnelle, je peux vous dire qu'il est beaucoup plus facile d'utiliser une technologie existante que d'écrire et de conserver la vôtre.

Answer 2

Eh bien, d'abord, je laisserais les connexions au référentiel. Deuxièmement, je ne garderais pas une connexion sur un objet - je ne l'utiliserais que pour une unité de travail (c'est-à-dire une seule méthode). Les chances sont que (en raison de la mise en commun) vous retrouverez la même connexion physique de toute façon. Le système va déjà un long chemin à gérer de telles choses afin que vous n'ayez pas à le faire. Le cas le plus difficile est celui des transactions, où TransactionScope est beaucoup plus facile que de passer un objet de transaction db.

Answer 3

Je ne pense pas qu'un objet métier doit savoir ou se soucier s'il est persistant. Un objet métier persistant individuel ne peut pas savoir quand il fait partie d'une plus grande unité de travail; C'est la responsabilité de la couche service. Laissez la connexion hors des objets métier. La couche de service est le bon endroit pour acquérir des connexions, généralement à partir d'un pool de connexions, définir des limites de transaction, valider ou restaurer et nettoyer.