Guy said that push models “requires defining in advance what should be pushed”. However, I’m not exactly in tune with this comment, since pull models also need to know what should be pulled!

I think the best way is to make the view dumb. If there’s something that needs to be shown, let the controller do the showing. The view needs to show the controller what is needed, but it doesn’t need to call the functions. In this way, the view exposes itself to the controller, and the controller pushes what needs to be pushed.

It means that you can test your program more thoroughly.

I never used the Magento e-Commerce Platform. But the way you describe how it works, sounds to me almost ideal. It combines the use of regular push model to create the main part of the content, and allows you to “pull” the other parts.

Similar, but maybe to a less extent, functionality is also provided in CakePHP by use of Elements.

Frameworks that only provide strict “push” model, like the second one you mention, in my opinion are less robust. While when well implemented this model can have higher performance (as it’s less complicated code-wise), the more configuration overhead leads to slower development. Furthermore, this model limits flexibility as it requires defining in advance what should be pushed (of course careful in-advance planning could work around it).

Magento also makes use of both described ways.
The general business logic is implemented in the controller actions that use models and push the results to the view.

But on more complex views especially when you have to conditionally load data you may use ‘blocks’, that itself have access to the needed models and get the data from them.

In my opinion this makes perfect sense. All logic that has to manipulate data in models only resides within the controller, so you should never put that part into such a block.

Furthermore I also worked with a framework that strictly enforces the ‘push’ model by defining all ‘blocks’, ‘widgets’, ‘portlets’ or whatever you call it, in a config file, so that all those parts will be invoked even before the templates are rendered. So the templates will never have to call methods for data retriving once the business logic is processed. This is a much ‘cleaner’ MVC approach by the cost of more configuration overhead.

Regards, Marc

Those documents below will help clarify this confusion

http://java.sun.com/blueprints/patterns/MVC-detailed.html
(The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view’s responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data. )

http://www.theserverside.com/patterns/thread.tss?thread_id=22143 Clarification on MVC Pull and MVC Push

Also, you said: “The Model is responsible for database access and executing queries” Please feel free to disagree with me but I am afraid that it is a bit misleading. What you said is about persistent layer, which sometimes is considered part of Model. “The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.” (Sun Microsystems documentation)