title: MVC and the Repository Pattern: Roles of Controllers, Models, and Repositories?
body: <p>So I've been studying the role of the repository pattern as a means of decoupling the persistence layer from my models in an MVC framework. Prior to this, I might have my <code>UserModel</code> calling active record methods directly in order to store/retrieve domain objects.</p>
  
  <p>Here's a sketch of what I'm thinking in regards to the call stack in a request that should create a new <code>User</code>: </p>
  
  <p><img src="https://i.stack.imgur.com/hOef0.jpg" alt="enter image description here"></p>
  
  <p>Here are my questions:</p>
  
  <ol>
  <li>Is this a correct implementation of the repository pattern?</li>
  <li>I understand that the controller should take the user's information from the request and pass it into the model. How does that usually happen? Should the controller create a User object and then pass that into the model? I sure as heck don't wanna just pass in an array of values into the model--nor do I want to pass in 15 arguments to the model method that creates a user.</li>
  <li>In order for this pattern to really work, it looks like to me I would need to have a domain object that is just a simple data structure with no behavior and then if I'm using an ORM, I would have an ORM object which will describe how the object is persisted. Initially I resisted this because it feels like duplicate code, but if I'm really separating persistence from the business logic, this would be needed right? For example, what if I went with an in-memory store? I would no longer use the ORM object.</li>
  </ol>
  
  <p>Am I thinking correctly here? Is this acceptable. Please help me connect the dots in my head.</p>