I intended to write this post couple of months ago, when I worked on a pull based MVC framework for some site. Most web-developers are acquainted with the MVC architecture and almost all the major web-frameworks uses this concept, including Ruby on Rails, CakePHP, Django, Symfony and others. So what is MVC and what’s the difference between pull and push?
MVC stands for Model View Controller, and represent a way to divide the application to three main parts: Model, View Controller. The Model is responsible for database access and executing queries. The Controller’s task is to handle the business-logic of the application, it should use the Models to access the database along with user-input to construct the information or execute the action the user wishes for. The View is the part visible to the user. Data generated by the Controller part is displayed via the View part, and input that the user enters in the View is passed on to the Controller.
So what pull and push has to do with this? Push and pull describe the relation between the View and the Controller. According to the push model, user actions should be interpreted by the Controller which will generate the data and push it on to the View, hence the “push”. On the other hand, the pull model assumes that the user requires some kind of output (like a list items from the database). The View will access the Controller in order to get the data it needs in order to display the user the kind of output he requested. This is much like the View is “pulling” data from the Controller.
Today, most web-frameworks only use one of the methods above, and do not implement both “push” and “pull”. While in the first look, it may seem good enough as in both ways you can achieve the desired functionality. However, some tasks are better suited by one of them than the other.
For example, when a user wants to make a specific action, like sending a comment, he excepts the action will be carried out, he is less interested in the way the output will tell him that his comment was sent. The user wants to initiate a specific action, which would be mapped to a specific method in on of the controllers. This controller will then “push” the result of the action to a view which shouldn’t care who pushed the data into it. As you can see, this is clearly the place to use a “push” model, because user actions are easily translated to a specific method in the Controller part, which will “push” the output to the View.
The “pull” method has its strengths too. Consider a case where a user asks for a list of customers and what products they bought. The user excepts a specific kind of output. The best way to handle this would be to pass his request to a view that will utilize the different controllers (like the one that handles the customers and the one handling the shopping carts of each customer) in order to create the output the user asked for. The way this request was handled was by the view “pulling” the data from the controllers.
Of course one can implement each one of the examples in both methods, but trying to do so will show you that implementing it in the other method will be more complicated. We can’t ignore the fact that “push” is much better at performing actions and tasks than the “pull” is, and “pull” is superior in handling request to show some kind of data. The framework I’ve built for that site supported both kinds of MVC, allowing us, the developers, to better chose the right way to implement each feature. I would really like to see some more MVC frameworks offering both methods, as I think it can offer great flexibility to the developers. I would really like to read your comments on this matter.
I believe that you are wrong on the relationship between Views and Controller to determine if an architecture is kind of Pull MVC or Push MVC. Pull or Push is about data, not about event. In fact, it is about the relation between View and Model.
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)
Hi pcdinh,
You’re arguments sound very interesting. It seems to me that you’re talking on a much more general way than me. In most MVC web-frameworks the Model refers to the database, as this is the common used persistent data storage. You’re right about the distinction between Push and Pull, it relates to the data. In push the data gets pushed by the Controller to the View, in Pull the data gets pulled by the view from the Controller. This is essentially what I said in the post. The whole thing with the user is to show how thing integrate in a more simple scenario (the user makes an action and how the system reacts).
change Mode View Controller to Model View Controller 😉
Changed, thanks
Hi Guy,
have you looked at the Magento e-Commerce Platform (based on ZendFramework)?
I worked with it the past months and I’m really impressed by it’s architecture.
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
Hi Marc,
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).
When you allow the view/gui pull data, it becomes too smart, in my opinion. I’d be of the opinion to have the controller push everything.
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.
What about View Helpers in the Zend Framework? Do they provide a kind of “pull” functionality when they are used to generate a page’s sub-contents such as sidebars?
I’m not familiar with the Zend Framework, but it sounds to me like a “pull” functionality. As the request for the sub-content is generated by the view and not the controller. It seems like it’s part of a combined push-pull. “Push” for the main content, “pull” for the sidebars and etc.
The Yii framework for PHP has something called Widgets:
http://www.yiiframework.com/doc/api/1.1/CWidget
These are essentially controllers with just one action, and although constructing them and configuring them ahead of time (passing them through the view-dictionary), you can also freely construct and run these from within the view.
Yii provides widgets for things like breadcrumbs, paging and menus. Would you consider those good condidates for “pull”?
Personally, I have always used “pull” for certain things – although in the strictest terms, Tom Anderson is correct in his comment above, and for that matter, I know some people who would claim that “pull” is not MVC at all, because you’re branching out of the view back into a controller, there is no longer any strict separation of the two. I still think it has legitimate uses for certain things though – especially when you don’t care how the data gets there, as long as it gets there.
nice article…very clear to understand..thanks…
I’m a bit late to discuss this post. However, I’d like to share my understanding of real-world application of MVC. I think MVC concept is a guide, not a rule and Sun’s article introduced by pcdinh is proned to seeing Model as a responsive object, whereas in many of the contemporary MVC frameworks see Model as an data object as Guy depicted in replied post. So it’s ok as long as the concept matches MVC spirit. Personally, I like to see push or pull as a relation between View and Controller since it’s more intuitional to we human being’s way to think things, IMHO.
But thanks to pcdinh’s debating, I now know why Sun calls it MVC rather than VCM that has been a long-time mystery to me.
The link provided above by ‘pcdinh’ regarding the differences between the push and pull mvc is no longer working, the correct link is:
http://www.theserverside.com/discussions/thread.tss?thread_id=22143
The information provided by is very useful and easy to understand thanks for clearing the topic so easily…….
At my last company I was poo poo’d for suggesting pulling, so it is good to see it here. The controller had to pass everything. HTML formatted too.
In my own mvc system the controller only ever pushes pure data, that way it can go into several views. The view generates HTML from simple php functions, or pulls from “view helpers” such as a drop down. The view contains an absolute minimum of conditional statements and loops.
It totally works for me.
As you explained, the actual pull-based framework’s View is performing the Controller’s Controller part right? One action allows many Controllers respond to Model. Relatively the push-based framework, allow only one Controller to perform a View, am I getting your point correctly?