MVP (Model View Presenter) or MVC (Model View Controller)

Question

I already know the difference between MVP and MVC. Then also after going through the SRS of an application i get in a Fix which one need to be picked, applied and followed as Applcation Architecture. As per my understanding I would pick MVP where there is the chances of using the Same Business Logic, from more than 2 GUIs. Like for a application with a public (www) and Adming (winform) part. If there is not such ... look for MVC. Because I can follow Factory patters more accurately.

Dudes, I don't know but I feel like I just play blind shot if I would got to choose among them. I need to know. What opinion you guys have over these?

Note: I follow .net and C#.

Answer 1

In my mind the differences for all variations of Model View Controller patterns (MVP, Passive View, Supervising Controller, View Model, etc.) are quite subtle. It's all about who processes the data and takes the data from who, really. They are all trying to solve the same problem, seperating something from another thing, and the solutions do all that in a similar fashion.

It is almost blatantly obvious that the concepts are similar in implementation when you think about it in visual terms:

Simplistic MVC:

+-------+       manipulates data
| Model |<---------------------+
+-------+                      |
    |                          |
    | gets data                |
    v                          |
+------------+ serves data  +------+
| Controller |------------->| View |
+------------+              +------+

Simplistic MVP:

+-------+
| Model |
+-------+
  |  ^
  |  | get/manipulates data
  v  |
+-----------+  serve data   +------+
| Presenter |-------------->| View |
|           |<--------------|      |
+-----------+  tell changes +------+

They're similar in that class hierarchy may look the same in both. The difference however are the different ways of displaying and manipulating data. When you're rolling out your own MVC then you're in charge of how it should look like.

It doesn't really matter that much since they are all based on a principle of seperating pieces of code into self serving logic entities and reducing code duplication. As long as you keep the code coupling low it should work out nicely in the end. It only matters if you want to be dogmatically consequent with your application's architecture.

Be pragmatic about it and do that what suits your needs the best since you'll end up with a mix anyway. It should be "fairly" easy to switch between the variations depending on what the view needs. Follow the SOLID principles and you should do fine. (See also this about SOLID).

I would suggest you look into if there are MVC or MVP frameworks to see how it is done.

Answer 2

I think you're on the right track here. MVP for apps with more than one GUI and MVC for web apps is my general guideline. If you do either one, I would use a framework such as ASP .Net MVC or Castle's MonoRail because doing the plumbing on your own can be a pain. There is a good reference implementation of MVC here based on the Northwind database that came with SQL Server 2000.

http://nsk.codeplex.com/SourceControl/list/changesets