title: How to implement the repository pattern the right way?
body: <p>When implementing the repository pattern for my ASP.NET project, I encountered some problems on which I can't get my head around. So I have a few questions on how to implement the repository pattern the right way.</p>
  
  <p>From my experience I think that having classes/models without behaviour only in my application, next to their repositories is not good OOP. But, this was the way I implemented the repository pattern. I just make everywhere I need an repository instance, to perform some actions. The result of this approach was that all my domain classes didn't have behaviour.</p>
  
  <p>They were just objects holding data with no methods. My teacher said to me that I was using thin models and that I should strive to make fat models.
  In response to that feedback, I implemented some business logic in the classes, but I ran into some problems:</p>
  
  <p><strong>Scenario:</strong></p>
  
  <p>My <code>User</code> class had a list of Friends with User objects in it, to represent the friends of a certain user. When adding a new friend to an user the domain class method checks if the "friend" already exists in the friends list. If not, he will be added to the list. These changes need to be sent to the database for persistence.</p>
  
  <p>I know this has to be done in the repository for each domain class, but where do the calls to the repository methods belong in the architecture of the application?</p>
  
  <p>Right now I call the repository methods in the domain class methods itself, to persist changes to the database:</p>
  
  <pre><code>public void AddFriend(User friend)
      {
          foreach(User f in Friends)
          {
              if(f.Username == friend.Username)
              {
                  throw new Exception(String.Format("{0} is already a friend.", friend.Username));
              }
          }
  
          Friends.Add(friend);
          userRepo.AddFriend(this.Id, friend.Id);
      }
  </code></pre>
  
  <p>Is this a good approach, because of some reason I think it's not. Regarding to unit testing, we need with this approach some dependancy injection, which says to me that it is not a independent class (good testable unit). I have read some posts from people saying they use an extra service layer or something. I think these kind of abstraction is needed here, but how does a certain service layer look like? What is in it, which methods etc.?</p>
  
  <p>I have seen some other students making use of static methods in a domain class which provides functionality like adding a new object, updating an object, deleting an object, and getting all objects.</p>
  
  <p>Example:</p>
  
  <pre><code>public class Tram
  {
      private static TramRepository Repo = new TramRepository(new DBTram());
  
      public static void AddTram(int tramID, TramType type, int lineNr)
      {
          Tram tram = new Tram(tramID, type, TramStatus.depot, lineNr, true, null);
          Repo.AddTram(tram);
      }
  
      public static List&lt;Tram&gt; GetAll()
      { 
          Repo.GetAll();
      }
  }
  </code></pre>
  
  <p>I find it a weird thing to have a method adding a new entity to the database in a domain class, which is that entity itself. Also for the GetAll() method, I think it's weird to have a method in a class itself that gets all trams. So a tram object can get all trams. I think this is a weird way of implementing the repository pattern. Am I right?</p>
  
  <p>So, what kind of abstraction is needed here? Does there have to be an extra layer? If so, how does this layer look like? (Example code) Or am I searching in the wrong direction and is there another solution that counters the problem of unit testing with the repository pattern?</p>
  
  <p>This architecture problem I encounter every time, made sure I need it to be answered.</p>
  
  <p>I find it hard to explain this problem clearly, but I hope you guys understand it.</p>