Quelle est la meilleure utilisation de Dispose pour "Entity Framework"?

Question

Quelle est l'utilisation réelle de disposer? C'est d'abord (ma) approche:

public class RequestService : IDisposable 
     { 
      requestDBEntities db; 
      public RequestService() //Constructor 
      { 
       db = new requestDBEntities(); 
      } 
     public List<RequestStatus> ddlFill() 
      { 
       return (from rs in db.reqStatus select rs).ToList(); 
      } 
      //Some Insert,Update,Delete methods {}... 

     public void Dispose() 
      { 
       db.Dispose(); //<--Dispose requestDBEntities(); 
       GC.SuppressFinalize(this); 
      } 

Et deuxième approche:

public class RequestService : IDisposable 
      { 
       requestDBEntities db; 
       public List<RequestStatus> ddlFill() 
       { 
       using (db = new requestDBEntities()) 
        return (from rs in db.reqStatus select rs).ToList(); 
       } 
      //Some Insert,Update,Delete methods {}... 

      public void Dispose() 
       { 
        GC.SuppressFinalize(this); 
       } 

page code-behind:

  using (RequestService _reqService = new RequestService()) 
       { 
       ddlRequestStatus.DataSource = _reqService.ddlFill(); 
       ddlRequestStatus.DataBind(); 

       //Some Insert,Update,Delete operations... 
       } 

Merci ..

Answer 1

Il est difficile (impossible) pour dire quelle est la meilleure approche, puisque nous ne connaissons pas votre choix de conception exacte. Du point de vue d'une application simple, il peut sembler que les deux exemples sont équivalents (plus ou moins), mais ils se comportent vraiment de manière totalement différente.

La question fondamentale ici est la suivante: La durée de vie de db devrait-elle être comparable à la durée de vie de son instance RequestService?

Si oui, alors le premier exemple de code est la façon de faire les choses. Les ressources seront gérées comme prévu (db dispose de ses données en même temps que l'objet RequestService est demandé de disposer de ses ressources), et la durée de vie des deux sera à peu près identique (db est construit dans le constructeur RequestService, et db deviennent collectable dès que son objet RequestService devient collectable).

Cependant, si la réponse est « non », le second exemple est (presque) la façon de faire les choses - puisque vous générer une vue de collection de l'objet RequestStatus de db, vous avez vraiment aucune raison de garder db autour plus longtemps. Cependant, pour faire un peu mieux, je suggère de restreindre la portée de db à l'intérieur de la méthode ddlFill:

public List<RequestStatus> ddlFill() 
{ 
    using (var db = new requestDBEntities()) 
     return (from rs in db.reqStatus select rs).ToList(); 
} 

Pas besoin d'un membre de la classe étrangère lorsqu'une valeur de la pile suffit. Qu'est-ce que, dans le deuxième exemple, vous avez déclaré requestDBEntities db;

Answer 2

au niveau de la classe au lieu de l'avoir comme une variable de pile? En comparant vos approches, la question est: êtes-vous prêt à créer requestDBEntities à chaque appel? Si vous êtes - la deuxième approche est meilleure, en fait s'il n'y a rien d'autre que vous n'avez pas affiché - vous n'avez pas besoin d'en disposer du tout. Mais vous aurez une pénalité de temps supplémentaire lors de l'instanciation/libération de requestDBEntities à chaque appel.