The Model or the Controller write data on the view in MVC and what is the use of the Model if we have data in Store?

Question

I've read several articles, watched videos and read questions on here, but the more I read and learn about MVC - including MVCS or MVP in addition.. to make it even worse - the broader the pattern seems, so I apologize if the question is broad or long it is just because I really want to figure it out and understand its combination.

First:

Is it the Model which writes, renders or updates data on the View, or it's the Controller, I've seen places where the developer uses the first approach, while the latter is used more - which makes more sense to me because of the view-controller pair and since the Model better be separated, or this what I think - but even with a simple block diagram, this varies a lot.

---

Second:

Having these generic logic codes for the two examples:

Example 1:

// UserModel:
function getUsersDetails(id= false){
    if(id){
        // Fetch that specific user details with the id provided
    }else{
        // Fetch all users details
    }
}
// UserController:
result = UserModel->getUsersDetails(id) // id is optional depending on the view

Example2:

// UserModel:
function getAllUsersDetails(){
    // Fetch all users details
}
function getUserDetails(id){
    // Fetch that specific user details
}

//UserController:

    //for ONE user details View
    result = UserModel->getUserDetails(id) 

    //for a View of ALL users
    result = UserModel->getAllUsersDetails() 

Which one of the above examples is the better approach, personally I guess it is the Example2 because of the "no logic in the Model" rule, but if so, this confuses me even more when some people say "No SQL in the Model, instead put it in repositories or a Store". If the Model should not contain logic, and better not contain SQL , what would it be consist of then, just empty methods calling functions from the repositories? wouldn't this make it unnecessary and add more complexity to the whole design.

I apologize if the post has many questions or it is broad and Thanks in Advance

Answer 1

MVC is a software architectural pattern for implementing user interfaces. Its concrete form highly depends on the technologies used, so it is difficult to describe how it works in detail outside the context of a specific stack of technologies.

Is it the Model which writes, renders or updates data on the View, or it's the Controller

The View has references to the Model, specifying which data is displayed how and where. The underlying framework or programming language makes sure that updates to the Model are automatically propagated to the View. The source code of the Model does not have explicit references to the View. The Controller may manipulate the View explicitly, not to change model data, but for user interaction purposes. The Controller should not directly change the presentation of model data, but should change the Model and, by doing that, change the View indirectly.

The above is the most common view on MVC, but this is not enforced by law.

Which one of the above examples is the better approach

This question is not related to the MVC concept. It is allowed to have business logic in the Model (e.g. validation checks), but it is not allowed to have user interaction logic in the Model. The logic you describe is neither business logic nor user interaction logic, but it is a matter of software decomposition. I think the second approach is better from a separation of concerns perspective: A single function should not both provide a collection of data and provide one item from that collection, depending on a special value of the parameter.

If the Model should not contain logic, and better not contain SQL , what would it be consist of then, just empty methods calling functions from the repositories?

It depends on your application architecture. For example, an application may consist of three layers: the database, a business logic layer or services layer on top of it and then a presentation layer. In that case, MVC is usually only applied in the presentation layer. It may (or may not) be a design decision to let business logic be executed exclusively in the business logic layer. In that case, the Model in the presentation layer does not contain any logic at all, it is just a bunch of data, supported by a framework or a programming language that makes sure that model data is synchronized with model data in the business logic layer and eventually in the database. But other architectures are possible too. It's up to the software architect to make the decisions clear.