MVC中的推与拉模式

转载于http://www.guyrutenberg.com/2008/04/26/
pull-vs-push-mvc-architecture/

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.

此篇文章已被阅读2236 次