Entity Framework - Comment dois-je instance de mon objet "Entities"

Question

Je suis un novice total chez Entity Framework et ASP.Net MVC, ayant principalement appris à l'aide de didacticiels, sans avoir une compréhension approfondie de l'un ou de l'autre. (J'ai de l'expérience sur .Net 2.0, ADO.Net et WebForms)

Mon doute actuel vient de la façon dont j'instancie mes objets Entités.

En gros, je le fais dans mes contrôleurs:

public class PostsController : Controller {

    private NorthWindEntities db = new NorthWindEntities();

    public ActionResult Index() {
            // Use the db object here, never explicitly Close/Dispose it
    }
}

Je le fais comme ça parce que je l'ai trouvé dans un blog MSDN qui me semblait assez autoritaire pour supposer que c'était une façon correcte.
Cependant, cela ne me semble pas facile. Bien que cela me fasse économiser beaucoup de code, je suis habitué à faire:

using (NorthWindEntities db = new NorthWindEntities() {
}

Dans chaque méthode nécessitant une connexion, et si cette méthode appelle les autres qui en auront besoin, elle leur passera la base de données en tant que paramètre. Voici comment j'ai tout fait avec mes objets de connexion avant que Linq-to-SQL n'existe.

L’autre chose qui me rend mal à l’aise est que NorthWindEntities implémente IDisposable, ce qui, par convention, signifie que je devrais appeler la méthode Dispose (), et je ne le suis pas.

Qu'en pensez-vous?
Est-il correct d'instancener l'objet Entities comme je le fais? Devrait-il prendre soin de ses connexions en les ouvrant et les fermant pour chaque requête?
Ou devrais-je le supprimer explicitement avec une clause using ()?

Merci!

Answer 1

Le contrôleur lui-même implémente IDisposable. Vous pouvez donc remplacer les éléments Dispose et disposer de tout ce que vous initialisez lorsque le contrôleur est instancié (comme un contexte d'objet).

Le contrôleur ne vit qu’une seule requête. Donc, avoir une utilisation dans une action et un contexte d'objet pour tout le contrôleur correspond exactement au même nombre de contextes: 1.

La grande différence entre ces deux méthodes est que l'action sera terminée avant que la vue ne soit restituée. Ainsi, si vous créez votre ObjectContext dans une instruction using au sein de l'action, ObjectContext aura été supprimé avant le rendu de la vue. Il vaut donc mieux lire quelque chose dans le contexte dont vous avez besoin avant la fin de l'action. Si le modèle que vous transmettez à la vue est une liste paresseuse semblable à IQueryable, vous aurez supprimé le contexte avant le rendu de la vue, ce qui provoquera une exception lorsque la vue essaiera d’énumérer IQueryable.

En revanche, si vous initialisez ObjectContext lors de l’initialisation du contrôleur (ou écrivez du code d’initialisation paresseux lors de l’initialisation de l’action lors de l’exécution de l’action) et que vous supprimez ObjectContext dans Controller.Dispose, le contexte sera toujours autour lorsque la vue est rendue. Dans ce cas, il est prudent de transmettre un IQueryable à la vue. Le contrôleur sera supprimé peu de temps après le rendu de la vue.

Enfin, je m'en voudrais de ne pas préciser que c'est probablement une mauvaise idée que votre contrôleur connaisse Entity Framework. Examinez l'utilisation d'un assemblage distinct pour votre modèle et le modèle de référentiel pour que le contrôleur communique avec le modèle. Une recherche sur Google va tourner un peu à ce sujet.

Answer 2

Vous faites valoir un bon point ici. Quelle doit être la durée de vie de l'ObjectContext? Tous les manuels de modèles et de travaux pratiques (comme celui de Dino Esposito Microsoft-NET-Architecting-Applications ) vous indiquent qu'un DataContext ne doit pas durer longtemps et qu'il ne doit pas être mis en cache.

Je me demandais simplement pourquoi, dans votre cas, ne pas avoir de classe ControllerBase (je ne suis pas au courant de l'implémentation de MVC, alors soyez avec moi), où ObjectContext est lancé une fois pour tous les contrôleurs. Pensez en particulier au modèle de carte d'identité , déjà implémenté par Entity Framework. Même si vous devez appeler un autre contrôleur que votre PostsController, il fonctionnera toujours avec le même contexte et améliorera également les performances.