Should a Model for a View be an Aggregate with its own Repository?

Question

Should the Model that will be passed to the view be completely defined by a single call to a single repository. In other words, is the Model a single Aggregate, or should my Model be constructed from separate Aggregates, each with its own Repository, in the service layer?

The way I have it now, is I simply call a single repository to fill the entire model that is then presented by View. Seems like Aggregates, Repositories and models are all becoming the same concept.

Answer 1

My that is for "None of the above." I prefer to use presentation models for views, and presentation models don't need a repository. There are a variety of reasons for this:

• Using presentation models allows you to design views and controllers before designing the model and database. So you can get user input early.
• Presentation models allow you to pass a fairly "flat" model to the view, so you don't need to worry about ORM concerns such as lazy loading.
• Presentation models often simplify model binding.
• When using a presentation model, you do not need to worry about accidentally returning fields a certain user should not be allowed to see, or accidentally updating fields that the user should not be allowed to update, because you did not get a whitelist correct.

Now, more specifically following the line of your question: Have you build an instance of the presentation model? How many repositories are needed? Well, this question now almost answers itself. You design the presentation model to follow the requirements of the view. You design the repositories following good TDD practices, including identification of aggregate roots. Now the question of "how many repositories do I need to instantiate this model" is straightforward. You examine the aggregate roots required by the model, and use the ones you need. Generally, I can do this in a single LINQ query.