MVC Pattern: Usage Best Practices

Question

I am striving to respect the best I can the MVC pattern. It simplifies the life of a developer (or devs) a lot. The thing that I am wondering about is how to load multiple sections at a time.

To make it clear, I am going to take the example of a to-do list (it's pretty used this days). Let's say there are project -> milestones -> tasks.

What we need:

• get them all - all the projects with all the milestones with all the tasks in a nested json encoded array.
• get only the projects
• get only the milestones
• get only the tasks

For the last three, we can have separate controllers that provide us with the corresponding data. The problem shows up when we try to "get them all" in a nested json-encoded array.

What is probably the best way to handle that?

I thought of a few possibilities:
- Move the project, milestone and task generators in helper classes - this means we call them from the individual controllers and also call them when we need to get them all
- From the view of the projects, call the controller/view of the milestones (of each project) [which in turn calls the controller/view of the tasks (of each milestone)]. This might look like a simulation of 3 requests in 1.

The motivation comes from the fact that while I could fetch all the projects and then the milestones of each and then the tasks of each milestone, it would take a lot of requests. If we could get all the calls in one, it would take considerably less time to get the data, let alone that in one request the data is more organized.

Answer 1

Make 3 independent JSON requests from browser. Don't worry. If you turn on Firebug, and open mail.google.com - you will see there more than 40 requests.

Answer 2

You definitely need to separate the data access concern into a logical layer that can be accessed from different controllers.

If you are willing to go down the DDD path, than it would make sense to identify your domain objects (Project, Task etc.), aggregate roots and then build repositories for data access. You can reuse the repositories (e.g. ProjectRepository, TaskRepository) in different controllers and the repository itself will be the unit of reuse that will allow you to get data from multiple controllers using the same interface. You can also leverage a unit of work if you need to get data from multiple repositories from the same controller efficiently.

If you are not going down the DDD path you can use an ActiveRecord pattern (like in Ruby on Rails) that will be a in-memory representation of a database record. This would be probably pretty simple to implement if you are using a relational SQL database.

I think that the Project in your case is the aggregate root, and that means you would have only one repository (ProjectRepository). That repository would have an operation to get all the projects and fetch all associated data (Milestones etc.) and that would be a fast operation optimized as close as possible to the data source (store procedure?). On the controller itself you would use the objects retrieved and serialize/encode to JSON.