MVC versus MVP

Model-View-Controller (MVC) vs. Model-View-Presenter (MVP). This is some topic that might be something you heard of somewhere around the web. If it is the first time you heard this -- then welcome to the Internet where you do things w/o knowing what technology you are using.

This two is a completely different design pattern when writing software and stirs some debate around the web to what is the difference and where each one is applicable. Now, let me try put my opinion about this and hopefully make it clearer and shed some light on what is the real difference between the two.

Let's start with a the pattern which is more popular on Web Developers - MVC

If you are using CodeIgniter or some sort of PHP framework. You'll find that it is all using MVC. That is because MVC fits perfectly to the behavior of HTTP which powers the Internet. In HTTP, you have an endpoint (a url) where you can invoke different operations (GET,POST,PUT etc.) and the url could either respond with something like a web page or non-normal-human readable data (like JSON or XML).

A single Controller can handle different methods and uses Models to retrieve data from the storage and format that data using any view. Thus, in MVC, Controller is the main entry point and is the rockstar of the application.

Look at the diagram above on how everything is funneled via controller. Then the controller decides what models and views to employ before responding to the user.

Now going to other side which is MVP.

In MVP, the View is the frontier of the gameplay. View accepts all things from the user, then an object called Presenter provides the behavior on each event raised by the View. So let's say a user clicked a button, then there is a onClick method of the Presenter for that. This event handler method then chooses the Model to get the data from, for it to update the view depending on the requirements of the view.

So let's say the View has a "Generate Report" button, the Presenter's btnGenerateReport_onClick method might get invoked which in turn instantiates the Report Model to get the required report data. After the data is acquired, the Presenter will fill the view with this data so that the user will be able to view the data.

If you'll notice, MVP perfectly fits for desktop applications wherein the "Forms" are created first before writing the classes that will handle the actions required by application.

Though it is easy to say that MVC is for web-based applications, while MVP is for desktop applications -- one can't just safely say that w/o bumping with ASP.NET or Java Server Faces developers.

Though MVC frameworks are available in both technology, you could somewhat develop a web application using MVP. This is because in those technologies, you can create the Web Forms (ASP.NET) or XHTML files (JSF) and bind the events raised by these user-interfaces to a class which will do the required behavior -- a signature behavior of MVP pattern.

Aside from this blurred line between the two. Each has its own complicated details which will I briefly mention here to further make some distinction between the two:

MVC is evolving to be more of Service-Oriented-Architecture (SOA) like Web Services, RESTful web services etc which has no real "view" to be consumed by user. That is, in MVC, the user could be just another program or server that polls data. There is also so called modular approach in MVC which aims to group each module in a trio in order to reduce dependency of each part to each other, called Hierarchical MVC (HMVC) . You can read more about HMVC here.

MVP on the other side develops many kind of variations on which the most popular is Passive View and Supervising Controller.

In Passive View, the View contains almost zero logic. It's sole purpose is to accept inputs from the user and delegate everything to the Presenter the things that needs to be done.

In Supervising Controller, the view binds directly to the Model and maps each property of Model to each component of the user-interface. Presenter's role in this kind of pattern is just to select the appropriate Model to bind with the view and everything will happen automatically since View and the Model syncs each other out via some well-defined interface.

There are lot of other complex topics circling this 2 technologies and I barely scratched them all, after all, I don't want to get so much detailed since that will confuse those people who just wants to grasp first the idea behind it. Feel free to expand the concepts or maybe correct it in case I said something off.

---

• ← Previous Post
• Next Post →