[FIXED] MVC in CakePHP 3 - Separation of concerns between Model and View

Issue

This is a general question about MVC, but the context is CakePHP.

The Cake documentation largely avoids discussing optimal placement of model-related code, such as queries. Perhaps for simplicity's sake, or to avoid imposing any ideas on how the developer wants to structure their app, they simply always document queries as being in the controller. Essentially, a Fat Controller pattern.

e.g.

The page requires 4 large queries to show different areas of data in the view "XYZ". The end result of the queries is a very specific set of data just for view XYZ.

Fat Controller

• Controller handles request
• Controller runs query on model 1
• Controller runs query on model 2
• Controller runs query on model 3
• Controller runs query on model 4
• Controller performs additional logic on data
• Controller sends data to view XYZ

In this situation, the controller is doing all the work and is simply leveraging Cake's built-in model framework features to query the correct tables. The model layer itself contains no custom code.

So the alternative is to use a Fat Model pattern, but then I don't feel that's correct either, particularly where the model is determining which data will be sent to the view.

Fat Model

• Controller handles request
• Controller calls on model 1 to retrieve data
• Model 1 queries and performs additional logic on data, sends back to Controller
• Controller calls on model 2 to retrieve data
• Model 2 queries and performs additional logic on data, sends back to Controller
• Controller calls on model 3 ...
• Controller calls on model 4 ...
• Controller sends data to view XYZ

This keeps the controller nice and clean, and it only serves to handle the request, delegate the retrieval of the data it needs and then forward it to the view.

The problem with this, for me, is that the model layer (probably in table classes) now contains very specific queries which retrieve data specifically formatted for view XYZ. If I want to change the data shown in view XYZ I make those changes in the model layer by modifying the methods which return the fields the view needs.

This seems wrong, and leads to large models which are bloated with tons of very specific functionality.

---

Question

• Which approach is better?
• Is there a third solution to this which allows the following separation of concerns:

Controller

• Handles the request
• Decides which data the view will need, but delegates the job to the model
• Forwards the data from the model to the view
• Stays thin

Model

• Handles all business logic and database querying
• Database query logic is ignorant of what the view requires
• Is not bloated with specific one-use functionality for specific views

Is there another layer which can bridge the gap between the controller and the model tables, or is it pointless? What would it be in a Cake context? Custom classes outside of Tables or Entities? I fully understand that the model layer does not just mean active records or database querying.

Solution

Also there are Components for collaborating controller codes in classes and helpers to collaborate view codes in classes. So to make your controller slim you can add components for each job and use them in controller instead of doing all the stuff in the controller actions.

It has another advantage. If you put repeatable code in components then you don't need to duplicate them in each view and you stay observing the DRY (don't repeat yourself) principle.

Answered By - Ali Asgari