MVC or MVP

Topics: CAB & Smart Client Software Factory
Jan 26, 2006 at 1:30 AM
originally posted by: Simon_Natanel

Hi,

I am trying to decide whether to use the MVC pattern or the MVP pattern. We have a console that deals with two kinds of data: real-time and additional data. The real time data will come from a participation engine that handles SIP messages. The additional data will be handled through web-services on demand.

Is this info enough in order to choose the right pattern?

Thanks.
Jan 26, 2006 at 4:34 AM
originally posted by: WalkingDisaster

I think it depends more on what your philosophy is. It seems that MVP is the best fit if you are doing any of the following:
a) Unit testing
b) Using the Controller for state management
c) Actively (as opposed to passively) interacting with the view from the Controller

MVC doesn't have any clear advantages (in my opinion) over MVP in a windows client, but if your developers are familiar with MVC and aren't interested in learning another pattern (shame on them), MVC still works. If both are new, just dive in to MVP head first. It will really make windows forms development much simpler... that is once you get past having 3-4 times the number of classes!
Jan 26, 2006 at 7:00 AM
originally posted by: BryanKnox

The key difference between MVC and MVP is in whether the view subscribes to model events (as in MVC), or presenter events (as in MVP). A presenter can provide more isolation between the view and the model than a controller does. So if your design could benefit from that additional isolation the MVP is a good choice. If your controller does not need to respond to events from the model and you don't need to isolate your view from the model then the MVC pattern might be the better choice.
Feb 2, 2006 at 8:53 AM
originally posted by: ChrisHolmes

Bryan touches on the reason I prefer MVP - the additional decoupling. I don't really like publishing events in the Model; not really the place for it in my opinion. I try and treat the Model like pure data with Business rules associated where need be. Events for UI interaction don't really fall into that category. I like the idea of the Presenter publishing events and handling the interaction between View and Model.
Feb 2, 2006 at 3:27 PM
originally posted by: Agda

unit testing is very good reason to use mvp.
that is why i am starting to use cab with mvp...
Feb 2, 2006 at 6:41 PM
originally posted by: eugeniop

Check the example included in the SC-BAT project: http://practices.gotdotnet.com/projects/scbat
Feb 2, 2006 at 10:43 PM
originally posted by: pariampampam

The MVC pattern originates from SmallTalk. As it seems, the Pattern does not apply well to applications developped nowadays (also see Martin Fowler on this: http://www.martinfowler.com/articles/enterprisePatterns.html). In fact, as soon as you have a service layer encapsulating your model, it will be hard to get the model notifying the view directly, so MVP seems to fit much better in this case.
Feb 4, 2006 at 1:19 PM
originally posted by: ChrisHolmes

"In fact, as soon as you have a service layer encapsulating your model, it will be hard to get the model notifying the view directly, so MVP seems to fit much better in this case."

That, to me, is the big issue. Sometimes we don't have control (and I suspect as time moves on and SOA becomes even more dominant than it is, this becomes even more true) over what a service might provide us in the way of model/objects. I don't know how you can assume your model is publishing view-specific events unless you have total control over both the application and the services. And even if you did have control and could guarentee control of future services, do you really want to write that tightly coupled code?

Of course you can wrap your objects coming from the service and write the events into that shell, but that's an whole layer of work that seems unnecessary to me.

I used to be really high on MVC, but I sure do like the Presenter pattern a lot better now :)