title: Is DbSet<>.Local something to use with special care?
body: <p>For a few days now, I have been struggling with retrieving my entities from a repository (<code>DbContext</code>). </p>
  
  <p>I am trying to save all the entities in an atomic action. Thus, different entities together represent something of value to me. If all the entities are 'valid', then I can save them all to the database. Entity 'a' is already stored in my repository, and needs to be retrieved to 'validate' entity 'b'.</p>
  
  <p>That's where the problem arises. My repository relies on the <code>DbSet&lt;TEntity&gt;</code> class which works great with Linq2Sql (<code>Include()</code> navigation properties e.g.). But, the <code>DbSet&lt;TEntity&gt;</code> does not contain entities that are in the 'added' state. </p>
  
  <p>So I have (as far as I know) two options:</p>
  
  <ul>
  <li>Use the <code>ChangeTracker</code> to see which entities are available and query them into a set based on their <code>EntityState</code>.</li>
  <li>Use the <code>DbSet&lt;TEntity&gt;.Local</code> property.</li>
  </ul>
  
  <p>The <code>ChangeTracker</code> seems to involve some extra hard work to get it working in a way such that I can use Linq2Sql to <code>Include()</code> navigation properties e.g.</p>
  
  <p>The <code>DbSet&lt;TEntity&gt;.Local</code> seems a bit weird to me. It might just be the name. I just read something that it is not performing very well (slower than DbSet&lt;> itself). Not sure if that is a false statement.</p>
  
  <p>Could somebody with significant EntityFramework experience shine some light on this? What's the 'wise' path to follow? Or am I seeing ghosts and should I always use the <code>.Local</code> property?</p>
  
  <p><strong>Update with code examples</strong>:</p>
  
  <hr>
  
  <h2>An example of what goes wrong</h2>
  
  <pre><code>    public void AddAndRetrieveUncommittedTenant()
      {
          _tenantRepository = new TenantRepository(new TenantApplicationTestContext());
  
          const string tenantName = "testtenant";
  
          // Create the tenant, but not call `SaveChanges` yet until all entities are validated 
          _tenantRepository.Create(tenantName);
  
          //
          // Some other code
          //
  
          var tenant = _tenantRepository.GetTenants().FirstOrDefault(entity =&gt; entity.Name.Equals(tenantName));
  
          // The tenant will be null, because I did not call save changes yet,
          // and the implementation of the Repository uses a DbSet&lt;TEntity&gt;
          // instead of the DbSet&lt;TEntity&gt;.Local.
          Assert.IsNotNull(tenant);
  
          // Can I safely use DbSet&lt;TEntity&gt;.Local ? Or should I play 
          // around with DbContext.ChangeTracker instead?
      }
  </code></pre>
  
  <hr>
  
  <h2>An example of how I want to use my <code>Repository</code></h2>
  
  <p>In my <code>Repository</code> I have this method:</p>
  
  <pre><code>    public IQueryable&lt;TEntity&gt; GetAll()
      {
          return Context.Set&lt;TEntity&gt;().AsQueryable();
      }
  </code></pre>
  
  <p>Which I use in business code in this fashion:</p>
  
  <pre><code>    public List&lt;Case&gt; GetCasesForUser(User user)
      {
          return _repository.GetAll().
              Where(@case =&gt; @case.Owner.EmailAddress.Equals(user.EmailAddress)).
              Include(@case =&gt; @case.Type).
              Include(@case =&gt; @case.Owner).
              ToList();
      }
  </code></pre>
  
  <p>That is mainly the reason why I prefer to stick to <code>DbSet</code> like variables. I need the flexibility to <code>Include</code> navigation properties. If I use the <code>ChangeTracker</code> I retrieve the entities in a <code>List</code>, which does not allow me to lazy load related entities at a later point in time.</p>
  
  <p>If this is close to incomprehensible bullsh*t, then please let me know so that I can improve the question. I desperately need an answer.</p>
  
  <p>Thx a lot in advance! </p>