Un DbContext par requête web… pourquoi ?
Source : Stack Overflow).)
NOTE : Cette réponse parle du DbContext d’Entity Framework, mais elle est applicable à tout type d’implémentation d’Unité de Travail, comme le DataContext de LINQ to SQL et l’ISession de NHibernate.
Commençons par reprendre les propos d’Ian : avoir un seul DbContext pour toute l’application est une mauvaise idée. La seule situation où cela a du sens est lorsque vous avez une application mono-thread et une base de données utilisée uniquement par cette seule instance d’application. Le DbContext met en cache les données, et elles deviennent obsolètes assez rapidement. Cela vous causera toutes sortes de problèmes lorsque plusieurs utilisateurs ou instances d’application travaillent sur cette base de données via l’utilisation du DbContext (ce qui est bien sûr très courant).
Mais je suppose que vous le savez déjà et que vous voulez simplement savoir pourquoi ne pas injecter une nouvelle instance (c’est-à-dire avec un cycle de vie transitoire) du DbContext à quiconque en a besoin. (pour plus d’informations sur pourquoi un seul DbContext - ou même un contexte par thread - est mauvais, lisez cette réponse).
Permettez-moi de commencer par dire qu’enregistrer un DbContext en tant que transitoire pourrait fonctionner, mais en général vous souhaitez avoir une seule instance d’une telle unité de travail dans une certaine portée. Dans une application web, il peut être pratique de définir cette portée aux limites d’une requête web ; d’où un cycle de vie par requête web. Cela vous permet de faire fonctionner tout un ensemble d’objets dans le même contexte. En d’autres termes, ils opèrent dans la même transaction métier.
Si vous n’avez pas pour objectif de faire fonctionner un ensemble d’opérations dans le même contexte, dans ce cas le cycle de vie transitoire convient, mais il y a quelques points à considérer :
- Comme chaque objet obtient sa propre instance, chaque classe qui modifie l’état du système doit appeler
_context.SaveChanges(). Sinon, les modifications seraient perdues, car chaque instance deDbContextpossède son propre ensemble de modifications. Cela peut compliquer votre code et ajoute une seconde responsabilité au code (la responsabilité de contrôler le
(Réponse tronquée)