In MVC pattern, can the Model interact / modify the View?

Question

The MVC pattern component interactions are described this way on Wikipedia:

The model is responsible for managing the data of the application. It receives user input from the controller. The view means presentation of the model in a particular format. The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.

I understand that the View should not be able to interact with the Model. But in most of the diagrams I find on the net, MVC is represented like this:

We can see that Model does interact with the View and is able to modify it, and it doesn't make sense. Doesn't the Model update the Controller, that updates the View?

What am I missing?

Dishtowel

Answer 1

The MVC architecture was created in the 1970s. Obviously there was no Internet at that time. In the original version, the Model directly updates the View through data binding, also known as publish/subscribe, also known as the Observer Pattern.

The Gang of Four Design Patterns book describes this MVC architecture in detail. A couple of quotes from that book are in another answer here.

The MVC architecture was very popular, and when the Internet came along, developers wanted to continue using it; but it didn't fit nicely into client/server applications. Thus was born "WebMVC", the version you most commonly see today. WebMVC is typically implemented as a layered architecture, which the original was not.

Confusion ensues when the two architectures are conflated. Often both are referred to simply as MVC. Even worse, related architectures such as MVP and MVVM can be called MVC.

Personally, I find the relationship between desktop MVC and web MVC somewhat like the relationship between Java and JavaScript. The latter piggybacked on the famous name of the former, to implement something significantly different.

related: Is it MVC when the view doesn't interact with the model?

Snowslide

Ok, this is exactly what I needed. Thanks. – Dishtowel

Answer 2

No you can't access view with model directly, you must access controller first as its MVC Pattern

Flub

Ok, Thanks. But my question is why? Why is the diagram "wrong" everywhere then? there must be a reason. – Dishtowel

Context. the diagram shows just one layer of design - how information flows in the MVC model and not how the MVC process operates. Some MVC processes do not even use a model - For example, a page that displays some action has completed successfully can have absolutely no model at all and just display a view saying "Success" – Tamikatamiko

@pixelda, as I understand, the view should not directly interact with model anyway. (if we ignore "data binding") – Dishtowel

@Dishtowel Model content does not usually change when we get to the point where the view is processing it (A current-time property might return a dynamic value). You don't want the model going off to get more values as requested by the view. Even if you can do this its anti-pattern. The model should mark a point in time in the lifecycle of the data as provided by the controller via the model. If you need a pattern outside of MVC then maybe something like SingalR might be used alongside the MVC pattern – Tamikatamiko

Answer 3

Diagrams - worth a thousand words! The precise words and context used in the diagram maybe doesn't tell a story of implementation, say in Microsoft MVC 5/6.

A user's interaction is with the controller. Not the view and not the model. Calling an action on a controller will return something (a view, a file, a redirect, etc.).

In the case of returning a view of information, the controller, having worked out what data the user is requesting can retrieve a model that fits the request, pass this into a view, and return the view result of this model.

In the diagram above it isn't clear that the controller is acting as the agent in moving the model into the view. the model does not decide on the view. Why? Depending on what is in the model returned the controller, a different view might be returned. That is why the controller is aptly named. It sits at the centre of affairs making decisions and moving objects around.

So what you are missing is some context about how the process of MVC occurs when implemented

Tamikatamiko

Thanks for this nice explanation of the MVC pattern (I really liked it !). but it doesn't exactly answer my question. – Dishtowel