Tuesday, May 8, 2012

MVC vs MVP Design Patterns

Post length: about 1000 words and about 3 pictures.

Background (skip if you want; it's all about me)

A while back, my company's leader asked me if I knew what the MVP design pattern was. Clearly it wasn't the minimum viable product or most valuable player. It was that model-view-presentation (MVP) pattern. I think it's being used a lot in GWT.

I only had superficial knowledge about a related pattern called the model-view-controller (MVC). Just enough knowledge to make the interviewer of my last job believe I'm a guru when I'm in fact a big fat phony.

The thing is I never used these patterns in practice, so I didn't really know what's going on.

Try searching the web and you'll find tons of information on both of these patterns. A lot of them are 10 pages long, full of UML diagrams and code. On the other hand, a lot of them contain a lot of handwaving. I don't blame them. They're accurate and complete, but that wasn't what I was looking for.

After much reading and asking my friends around, I figured that not only were the patterns pretty easy to understand, but the idea behind it was also SUPER simple and is just object oriented common sense.


So there are 3 things
- MVP Supervising Controller (ooh big name)
- MVP Passive View (ooh another big name)

After you read this post, and if I did a good job explaining, you should be able to throw these 3 things away because it doesn't really matter how you name them.


You wanna go home

Suppose you're from Thailand. You've come to USA and during vacation, you want to book a flight back to your hometown.

You don't have time for this so you asked your brother, Tony Jaa, in Thailand to help find info about the flights from Thai Airway.

Tony goes to Thai Airway's homepage. They update their flight info regularly according to the laws, fuel price, and market demand.

The flight info includes the flight rates, departure/arrival times, and the food menu served on board.

When this info is ready, they put it on their website, into a spreadsheet.

You ask him to copy and paste the flight info and
- send it to you by email
- send it to the printer to print it out and hand it to your mom

In MVC terms
ModelThe flight info spreadsheet.
ViewYour view is an email which shows that spreadsheet.
Your mom's view is the spreadsheet printed on paper.
ControllerTony is the controller.
He accepts your order and go gets the data, creates the model (flight info spreadsheet) and shows them to you and your mom.

Note that you and your mom see the actual spreadsheet data exactly as on the website.

Your boyfriend wants to join

Later on, your boyfriend, Stephen Chow, who's Chinese finds out that you're going to Thailand and wants in. He wants the flight info to be sent to him through a Facebook wall post.

The problem is the flight info includes the menu served on board, which is in Thai and Stephen won't know what's on the menu.

Luckily Tony knows Cantonese (one of my favorite languages), so before he sends the email to Stephen, he also translates ONLY the menu part before sending it out.

In MVP (Supervising Controller) terms
ModelSame as MVC.
ViewSame as MVC plus the spreadsheet posted on Stephen's facebook wall.
ControllerTony is the presenter. He does the same for you and mom.
For Stephen, he translates the menu part and leaves the other data as is.

Note that in this case, the spreadsheet is massaged a little bit before it's posted on Stephen's wall.

You wanna go home cheaply

Finally, you figured that you don't really care about the spreadsheet. You're a cheap person and only care about booking the cheapest flight.

This time you ask Tony to only send out the cheapest flight info on that spreadsheet, and don't forget to translate the menu for Stephen.

In MVP (Passive View) terms
ModelSame as MVP (Supervising Controller).
ViewSame as MVP (Supervising Controller), just showing less info.
ControllerTony is the presenter.
He filters unneeded info, translates when necessary, and sends the info out.

Note that the original spreadsheet is no longer seen by you, your mom, and Stephen. There's only the cheapest flight info.

Bottom Line

In the end, all patterns do the same, they try to cleanly separate responsibilities, which is object oriented common sense.

Model: Somebody who manages the raw data should be smart only about the data. In this case, the airlines need to know how to calculate the flight info and stuff before publishing the spreadsheet.

Controller/Presenter: Somebody who knows how to get info and send them out should be smart only about getting the right info and sending the right info out. In this case, Tony needs to know how to copy and paste before sending the info to different platforms, including email, the printer, and Facebook.

View: Somebody who knows how to display data should be smart only about showing the data to other people. In this case, my Gmail web app should know how to show the spreadsheet in my web browser. The printer should know how to print the spreadsheet onto paper. Facebook should know how to display the spreadsheet on its wall.

These patterns are only different by the amount of coupling between the view and the model. Some applications can use the data from the model directly. And a lot of times, it needs to do something more complex to the data such as Cantonese translation.

And the names are there just so you have a common language to communicate with other people in the field who already knows this.

That's MVC and MVP for you.

1 comment:

  1. Great explanation. The MVC pattern is a must for any web based technology. I've had to deal with some old .cgi scripts that smash an entire website into one or two 1500+ line scripts! MVC defiantly lets you keep the code clean, and interchangeable. One thing that goes hand in hand with MVC is "separation of concerns". This keeps the views presenting data, controllers modifying it, and data layers storing it.