title: Entity Framework vs repository pattern
body: <p>I'm wondering about usefulness of repository pattern in project using Entity Framework. There are opposite claims about this - some say that EF is implementation of repository and Unit of Work pattern itself, so there is no need to wrap it in next abstraction layer, some argue that it has advantages like separation of DAL and BL and easier creation of unit tests. In my experience, I often come across the following approach (generally, not only in EF projects):</p>
  
  <pre><code>Repository (DAL) &lt;-&gt; Service (BL) &lt;-&gt; Controller
  
  Repository + Service + Type = Model
  </code></pre>
  
  <p>Repository has methods responsible for data access only i.e.:</p>
  
  <pre><code>public interface IUsersRepository
  {
    IEnumerable&lt;User&gt; GetAll();
    User Get(int id);
    User GetByLogin(string login);
    void Update(User item);
    void Delete(int id);
    void Delete(User item);
    // ...
  }
  </code></pre>
  
  <p>Often, there is used generic repository instead, which methods receive functions for filtering, sorting etc.</p>
  
  <p>Service in turn uses repository and contains business logic i.e.:</p>
  
  <pre><code>public interface IUsersService
  {
    // ...
    bool VerifyPassword(string login, string password);
    void ChangePassword(string login, string password);
    // ...
  }
  </code></pre>
  
  <p>As I understand, service shouldn't have any DAL operations - this means that we shouldn't i.e. return IQueryable collections from repository, because then query will be executed outside repository and unit tests will not be fully reliable (differences between LINQ-to-Entities and LINQ-to-Objects).</p>
  
  <p>I see a problem with queries efficiency here - we will often get more data from database than needed and then filter it in memory. </p>
  
  <p>For example, let's consider <strong>bool VerifyPassword(string login, string password)</strong> method. </p>
  
  <p>In this case we need to get whole User entity from database, which can have 50 properties for example, for password verification purpose only. We can, of course, create many methods in repository like :</p>
  
  <pre><code>string GetPasswordHash(string login) 
  </code></pre>
  
  <p>or </p>
  
  <pre><code>bool VerifyPassword(string login, string passwordHash) 
  {
    return db.Users.Any(x =&gt; x.Login = login &amp;&amp; x.Password = passwordHash);
  } 
  </code></pre>
  
  <p>without need to get whole entity from database, but in my opinion this can be a "little" overhead.</p>
  
  <p>We can also move VerifyPassword function from service to repository - then we should ask ourself a question whether two layers - repository and service are needed. But if we merge them, we will lose benefits of separating DAL and BL layers - unit tests would be integration tests in reality. So maybe it would be simplier (and better) to keep it all in controller and inject mocked DbContext or use something like Effort for unit tests?</p>
  
  <p>I will be grateful for your answers how you see this and how you solve this problem in your projects.</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>I understand that repository pattern allows to easily change data source/provider to other like nHibernate, LINQ-to-SQL, plain ADO and so on. </p>
  
  <p>But could you tell me how do you implement sorting and paging in your repository API? I mean what's the best way to pass sorting and paging specification to repository? I see that some passes function predicates for LINQ but this will tightly couple repository with LINQ - using it with plain ADO, stored procedures etc. would be problematic. Creating many methods like GetUsersOrderedByNameDesc() etc. is crazy in my opinion. So maybe create your own class for specification, forge and pass sorting/paging criterias, and process it in repository? If yes, can you provide me some example of implementation?</p>