Composite UI Application Block (CAB) is really a powerful framework for smart client applications. It comes with samples implementing the Model View Control (MVC) pattern and the Model View Presenter (MVP) pattern. There is actually a third pattern called Presentation Model. See the pictures from http://jgoodies.com/articles/patterns-and-binding.pdf.
As described in Martin Fowler's article (MVP, PM), the presenter in MVP has no state and the views need to provide interface allow presenter to manipulate them. The Presentation Model holds and synchronizes the state, but no need to create view interfaces.
Choice between MVP and PM, as per Martin Fowler's article:
The difference is that in MVP the presenter uses the interfaces to push data into the views. That presenter refers to views. In PM, views pull data from the presentation model. Views refer to pm via interface. The pm implements the interfaces. Personally,
What esstentially MVP and PM do is to take the state and behavior of the presentation out of view. The views are dumb. They do nothing other than data binding and bypass user inputs.
But in MVP, although it splits one "autonomous View" into two parts, actually presenter and view are logically one thing, physically two class. When adding a new view, a new presenter is required.
In PM, it is a decoupled structure. Presentation model has no idea about view(s). It just holds the state and raise events. Adding new views needs no changes to the PM. View can also choose to connect different presentation model.
Compare to MVC or MVP, I prefer using the Presentation Model, because it has a centralized place to store state/data and centralized event source to notify views to update themselves.
The CAB's Event Broker is perfect for notification. .NET 2.0's object binding is perfect to synchronize state between PM and Views.