MVC or MVP? Which design pattern makes the most sense?

Question

Which do you guys prefer? I've been looking into both and there definitely seems to be some inconsistency in what people call them.

I will try and jot down what the differences are and you can correct me if I'm wrong.

MVC

1. Model holds references to it's own observers (Views), on updates to the model it notifies observers.
2. Views pass all events and messages to the Controller. Views update their content when they are notified by the model that a change has occured. View holds a reference to the Controller and to the Model.
3. Controller holds the Model and (sometimes) the Views. The Views will call the Controllers methods corresponding with user input, the Controller then maniuplates the Model as accordingly, and sometimes manipulates the View (blocking out buttons on certain View clicks, etc. )

MVP

1. Model has no references to the View. Only provides the data abstraction for the program. Model holds no reference to anything.
2. As in MVC Views call the corresponding Controller methods depending on user input. View has a reference only to the Controller.
3. Controller has a reference to the Views and the Model. When a View calls a method in the Controller, the Controller manipulates the Model then manipulates the View.

I'm pretty sure I understand how MVC works, just my understanding if MVP is kind of iffy. I really really like MVC, but the only part that doesn't sit that well with me is the fact that the Model, which is supposed to only be an abstraction of the data layer, also holds references to Views and does updating. That doesn't make sense.

Answer 1

Assuming my understanding is correct, the Model should not hold a reference to a View in MVP or MVC.

I will say this though, your definition of exactly how MVC/MVP should be implemented may be slightly different than the next guys. I think the pattern is there for the general idea of the separation of concerns, but it can be adapted to fit exactly what you need for a specific implementation.

Answer 2

I think it depends on the environment you're in. In a web environment, the controller chooses which view to show, as a result of the request. Before that happens, the controller checks if there are any changes in the model. In other words, the view needs no direct connection with the model.

Answer 3

What about MVVM? (Model View View-Model) In this style, the model doesn't hold any references to a view and vice versa. I won't pretend to know much, because I am only just starting to learn it, but we recently made a choice to move to this Design Pattern, so I'm assuming it does have some merit.

http://en.wikipedia.org/wiki/Model_View_ViewModel

Answer 4

Martin Fowler offers an analysis of MVC and MVP, and the Wikipedia MVP article gives more references.

For me, there are two questions:

1). How "live" is the Model-View relationship? If the Model changes dynamically, and the View(s) must update to reflect that Model change then we have classic MVC, and the Model somehow notifies the relevent Views of changes. This style doesn't apply to classic Web Apps (for example as implemented in Struts). Here there typically is a View created as a one off of a snapshot of the Model (indeed often on DTOs provided by the Model). In much literature the Web-style is still referred to as MVC.

2). When the user does "something", who is responsible for ineterpreting and acting. In MVC this is typically the Controllers job. MVP appears to allow for more direct interaction from View to Model for this purpose (if I understand Fowlers article correctly).

I much prefer clean separation of concerns - the MVC approach is how I think, but that may just be a familiarity thing.

What should a person pick? Generally, I think you are driven by the framework you choose to use. I come from a Struts background, so web-style MVC is natural for me. If I understand correctly MVP has explicit adoption in some aspects of .NET. I would go with the flow of whatever framework you choose, and I wouldn't reject a framework just because it is MVP rather than MVC - even assuming that a clear-cut distinction could be made.

Answer 5

In either pattern the Model can't depend on any other components. 'Has references' only to Observer objects. It doesn't care if those observers are views, controllers or other models.

MVC is the most misquoted design pattern and lacks a real definition. I'm going to use the one published by Martin Fowler.

Let's consider a UI /a CRUD screen/ for a complex business object in a desktop application. (The Struts like MVC is a bit different). You have one Model (the business object), several views on the screen, each view having its own controller.

The UI logic (validating, enabling widgets pertaining to the Business Object) is scattered throughout the View and Controller objects. In this sense the MVC pattern is obsolete(!) though back then the separation of concerns was revolutionary and enabled richer UIs.

In MVP you have the model, a View, which is dumb, all the UI logic is inside the Presenter. The Presenters supplies the View elements with Actions/Event handlers/Delegates. So the View only calls back to the Presenter when the user interacts with the corresponding widget on the screen. The Presenter acts as a Mediator, encapsulates how the widgets interact.

I really recommend this link http://martinfowler.com/eaaDev/uiArchs.html. The whole MVC topic is not that easy as it might sounds. It's almost a theory on its own.