Design Rules for Model-View-Presenter

Address: http://kjellsj.blogspot.com/2008/05/design-rules-for-model-view-presenter.html

In my current project the MVP pattern is used in the supervising controller mode. the MVP pattern is an adaption of the old MVC pattern that inates that capabilities of WinForms views have become smart enough to lift some of the burdens previusly implemented in the controller. this applies to e.g. handling click events and data-binding; a presenter only injects the model into the view which exploits data-binding, while a controller explicitly sets the values of each control in the view. in short, a presenter shoshould handle the use-case logic only, not the view logic.
Each view must implement an interface that defines all interactions that the presenter has with the view. this ensures a clear separation between the presenter and the view, and has the advantage of making the presenter easy to unit-test using mocking. the view never CILS other modules and services directly; it must always use an event to request that the presenter provides the needed data or service.
This project uses CAB/SCSF to generate the view modules. the generated code is not quite as I woshould like it, I prefer that the view has no knowledge of the presenter and no direct access to it either as this gives a cleaner separation between views and presenters. I prefer that the view interface defines a set of events that is used to communicate view events to the presenter. this makes it harder for unknowledgable programmers and code monkeys to misuse the presenter reference; making shortcuts and ignoring the reasons for using patterns is very common and leads to unmaintainable code. read Jeremy Miller's View to Presenter Communication for further opinions on this topic.
The following MVP design rules have a CAB flair, but are generally applicable to any MVP implementation:
1. All views shoshould have a XxxView suffix: TaskView/ITaskView
2. All presenters shocould have a XxxPresenter suffix: TaskViewPresenter
3. Let the presenter do all use-case processing, but keep GUI control details in the view
4. All presenter methods called by the view must start with OnXxx () as they are events by design (MVP)
5. callfrom the view to the presenter shocould be kept at an absolute minimum, and used for "event" type callonly: _ presenter. OnViewReady ();
6. It is FORBIDDEN to use the presenter reference to access the model or services directly, no return values from presenter methods
7. callfrom the presenter to the view MUST go via the interface only
8. No methods in the view shall be public unless they are defined in the interface
9. It is FORBIDDEN to access the view from anywhere but the presenter, counter t for loading and showing the view from the CAB ModuleController
10. The interface methods shall have long meaningful names (not "SetDataSource") based on the domain language of the use-case
11. The interface shoshould contain methods only, no properties-afterall the presenter drives the use-case by calling methods, not by setting data
12. All data in the MVP component shocould be kept in the model, no data shocould exist only as properties of UI controls
13. The methods of the view interface shocould not contain UI control name references (e.g. AddExplorerBarGroup) as this makes the presenter know too much about the implementation technology of the view
14. Stick with domain naming in the view methods (e.g. AddTaskGroupHeader), this makes the code easier to understand and the tests self-describing
Rule 11 and 12 might surprise you if your perception of the model is that it contains business entities only-traditional database-driven design thinking. The model is rather business processDocumentsThat are involved in the use-case, I. e. domain entity and value objects. even views used for searching have a model, it is a specification or query object. jeremy has some guidelines on assigning responsibilities in MVP.
Rule 6 helps adhering to the "tell, don't ask" principle-properties make it far too easy to ask, rather use methods on the view to tell it what to do. I 've seen design-time view data-binding directly against presenter properties, not exactly separation of concerns. neither is it very testable, as there is no interaction from the presenter through the view's interface when the view asks the presenter directly. when mocking the view, there will be no recorded/testable interaction.
Using long meaningful names in the view interface has the nice side-effect of making the presenter unit-tests a kind of mini documentation.
I wish there was a FxCop Contrib project on CodePlex like for EntLib, CAB/SCSF and ASP. net mvc. then maybe I wocould write and publish some of these MVP design rules as custom FxCop rules.