title: Managing DbContext in WPF MVVM application
body: <p>I've been banging my head with this for days and still can't decide on which is the correct approach.<br>
  This question is targeting <code>WPF</code> specifically since as opposed to a web-application, many posts and articles online recommends a <code>context</code> per <code>view-model</code> approach and not a <code>context</code> per <code>request</code>.<br>
  I have a <code>WPF MVVM</code> application which is using an <code>Entity-Framework DB first</code> model.<br>
  here is an example of two models used in my app (created by <code>EF</code> Designer):</p>
  
  <pre><code>public partial class User
  {
      public User()
      {
          this.Role = new HashSet&lt;Role&gt;();
      }
  
      public string ID { get; set; }
      public string Name { get; set; }
  
      public virtual ICollection&lt;Role&gt; Role { get; set; }
  }
  
  public class Role
  {
      public Role()
      {
          this.User = new HashSet&lt;User&gt;();
      }
  
      public int ID { get; set; }
      public string Name { get; set; }
  
      public virtual ICollection&lt;User&gt; User { get; set; }
  }
  </code></pre>
  
  <p>I've narrowed my options on how to handle this to the following:  </p>
  
  <p><strong>1)</strong> Creating a <code>DataAccess</code> class which creates and disposes of the <code>DbContext</code> on each method call:</p>
  
  <pre><code>public class Dal
  {
      public User GetUserById(object userId)
      {
          using (var db = new DbEntities())
          {
              return db.User.Find(userId);
              db.SaveChanges();
          }
      }
  
      public void RemoveUser(User userToRemove)
      {
          using (var db = new DbEntities())
          {
              db.User.Remove(userToRemove);
              db.SaveChanges();
          }
      }
  }
  </code></pre>
  
  <p>which I can use in my <code>ViewModel</code> as follows:</p>
  
  <pre><code>public class UserManagerViewModel : ObservableObject
  {
      private readonly Dal dal = new Dal();
  
      // models...
      //commands...
  }
  </code></pre>
  
  <p><strong>2)</strong> Similar to approach 1 but without the <code>Using</code> statements:</p>
  
  <pre><code>public class Dal : IDisposable
  {
      private readonly DbEntities db = new DbEntities();
      public User GetUserById(object userId)
      {
          return db.User.Find(userId);
          db.SaveChanges();
  
      }
  
      public void RemoveUser(User userToRemove)
      {
          db.User.Remove(userToRemove);
          db.SaveChanges();
      }
  
      public void Dispose()
      {
          db.SaveChanges();
      }
  }
  </code></pre>
  
  <p>The use is the same inside the <code>ViewModel</code></p>
  
  <p><strong>3)</strong> Create a <code>repository</code> for each <code>entity</code>. Looks the same as the above options (also has the with or without the <code>using</code> dilemma), however every repository contains only methods related to its <code>entity</code>.<br>
  Afaik the use is the same as above inside my <code>ViewModel</code>.</p>
  
  <p><strong>4)</strong> Create a <code>Unit-Of-Work</code> class that will pass the appropriate<code>Repository</code> on demand:</p>
  
  <pre><code>public class UnitOfWork : IDisposable
  {
      private DbEntities db = new DbEntities();
  
      private IUserRepository userRepository;
      public IUserRepository UserRepository
      {
          get
          {
              return userRepository ?? new UsersRepository(db);
          }
      }
  
      public void Save()
      {
          db.SaveChanges();
      }
  
      public void Dispose()
      {
          db.Dispose();
      }
  }
  </code></pre>
  
  <p>and use it inside my <code>ViewModel</code> as follows:</p>
  
  <pre><code>public class UserManagerViewModel : ObservableObject
  {
      private readonly UnitOfWork unit = new UnitOfWork();
  
      // models...
      //commands...
  }
  </code></pre>
  
  <p>Which of the above approach (if any) is preferred in terms of in terms of data concurrency, better abstraction and layering and overall performance?<br>
  <strong>EDIT -</strong> Found the following paragraph in <a href="http://msdn.microsoft.com/en-us/data/jj729737.aspx">this article.</a> : </p>
  
  <blockquote>
    <p>When working with Windows Presentation Foundation (WPF) or Windows Forms, use a context instance per form. This lets you use change-tracking functionality that context provides.</p>
  </blockquote>
  
  <p>However, it raises the question of whether I should create a <code>DbContext</code> object in my <code>view-model</code> or is it better to have a utility class such as my <code>DAL</code> class and reference it.   </p>