Traditional MVC design pattern

Question

I have several questions about the Model-View-Controller architecture. I am a bit confused with all the conflicting information and different diagrams on the MVC pattern I've found on the Internet.

1. Is the diagram below a correct representation of the MVC flow between the layers? If so, is View allowed to update Model directly not via Controller?

2. What is the difference between the passive Model and the active Model and how does each of these variations impact the Model change propagation to Controller and View?

3. How is the new data fetched to both View and Controller after Model update (with and without Controller interference in Model update)

3a. (active Model - observers, notifications) Are both View and Controller notified each time Model updates and they get the new data from Model?

3b. (passive Model - no notifications) Does Controller receive updated Model state after it delegates Model update and notifies View about Model change?

I would be grateful for any piece of help with understanding the MVC.

Answer 1

The constraints are usually laid out by the implementation you use. Considering the web, Symfony has other thoughts about MVC than ASP.NET, for example.

In a web context, nobody "notifies" anyone, it's all stateless and based on HTTP requests and responses. A controller can receive a model as POST body or bind it from GET parameters, or look up an entity based on an ID.

Usually, an HTTP request triggers a controller to execute a method, which ends in something like return View($model). This View() method will then render the model to a template, returning the generated HTML to the browser. I wouldn't call that notifying nor updating a model.

When a "view" (which by that time is rendered as HTML in a user's browser) contains a form, it can POST the user-modified model back to a controller. Does this count as a view manipulating a model? The model doesn't exist in the browser. There's just a form. The controller reconstructs the model from request data and probably database data. This model is passive, just a dumb Data Transfer Object with properties holding data.

In desktop applications or otherwise stateful applications ("clientside MVC"), things do notify each other about updates through observers, listeners and whatnot. There's one "instance" of a model, and it lives in the client application. This can be considered an active model.