MVC: Model View Controller -- does the View call the Model?

Question

I've been reading about MVC design for a while now and it seems officially the View calls objects and methods in the Model, builds and outputs a view.

I think this is mainly wrong.

The Controller should act and retrieve/update objects inside the Model, select an appropriate View and pass the information to it so it may display. Only crude and rudiementary PHP variables/simple if statements should appear inside the View.

If the View gets the information it needs to display from the Model, surely there will be a lot of PHP inside the View -- completely violating the point of seperating presentation logic.

Answer 1

As with all things programming we need to be pragmatic. A view should only contain presentation logic. That logic can be very simple or can be quite complex. As long as that logic only handles what is displayed on the screen, printed on the report, etc.

The Controller should act and retrieve/update objects inside the Model, select an appropriate View and pass the information to it so it may display.

What is this information you are passing? Possibly a subset of a model. You could create a new class containing only the information the view should know about or just pass along the model and make sure you only access appropriate data. Anyway, the view should be free to query this passed in model to be able to display a view.

The point of controversy is if you from the view should be able to update the model directly, bypassing the controller. This is where the pragmatic side comes in. I think there are cases that can warrant updating the model directly. Especially if you can use data bindings. The you can assign a text box to a property of the model and let the update automagically happen. If there are a lot of simple property setting this approach can save a bunch of code in the controller. MVC is not a set of rules set in stone. It's guidelines that when used correctly can produce better code but if used too rigorously can lead to pain and suffering.

Be pragmatic!

Answer 2

There isn't one absolute and correct way to do MVC. Variations are possible.

For example, instead of having the View actively querying the Model, the Controller can notify the view of any changes in the Model, using some sort of notification mechanism. In that case, the View is just listening for updates, which are then being presented.

Answer 3

It's probably not what one would call "pure" MVC, but IMHO it's not a huge deal as long as the view PHP code doesn't mutate the model. The most important rule of MVC is that the model doesn't know about the view. Having the view not know about the model is less important.

The main downside to using the model directly is that the view can't be reused with a different model. This is rarely a problem, because the view is almost always specific to one particular type of model object (or a list thereof).