Le référentiel Linq to SQL doit-il implémenter IDisposable?

Question

J'ai passé en revue une tonne sur les modèles de référentiel avec Linq au cours des derniers jours. Il y a beaucoup d'informations là-bas mais c'est souvent contradictoire et je suis toujours à la recherche d'une source définitive. L'une des choses dont je ne suis toujours pas sûr est de savoir si le référentiel devrait instancier son propre DataContext et avoir une méthode SubmitChanges, ou si le DataContext devrait être injecté et la soumission traitée de manière externe. J'ai vu les deux modèles, mais pas de véritable commentaire sur le raisonnement.

Quoi qu'il en soit, le modèle suivant est assez commun

class Repository<T> 
{ 
    DataContext db = new LinqDataContext(); 

    public IEnumerable<T> GetAll() { ... } 
    public T GetById() { ... } 

    ... etc 

    public void SubmitChanges() { ... } 
} 

Donc, ma question principale est, avec la mise en œuvre ci-dessus, pourquoi ne le dépôt pas besoin de mettre en œuvre IDisposable? J'ai vu littéralement des centaines d'exemples comme ci-dessus, et aucun d'entre eux ne semble déranger le DataContext. N'est-ce pas une fuite de mémoire?

Answer 1

La disposition d'un DataContext ferme la connexion sous-jacente si le paramètre autoclose est défini sur false. Si vous n'appelez pas éliminé, vous devez attendre que le CPG l'appelle pour vous. Vous devez implémenter IDisposable et disposer de vos référentiels qui doivent à leur tour disposer de leur DataContext.

Une autre solution consiste à créer un nouveau contexte de données pour chaque méthode dans votre référentiel si vos méthodes ne fonctionnent pas ensemble au sein d'une même transaction. Vous pouvez ensuite disposer vos contextes dès qu'ils sont utilisés via une directive using().

Answer 2

Not necessary mais vous probably should implementIDisposable.