当我们谈论MVP的时候，我们在说些什么-14条军规

下面我简单翻译的关于MVP设计模式中的14条准则：

1. 所有的View都应该以View后缀结束：TaskView/ITaskView
2. 所有的Presenter都应该以Presenter后缀结束：TaskViewPresenter
3. 让Presenter来处理所有请求，View仅处理GUI的操控细节。换句话说，就是View不处理具体的业务，应该交由Presenter来处理，View仅仅响应用户操作，以及完成数据绑定。
4. View对Presenter方法的调用应该像事件触发一样：OnXxx（）
5. View对Presenter的调用应该尽量少，而且只能是第4点的调用方式
6. 禁止通过Presenter直接访问Model或者Service取得结果，Presenter的方法都应该是无返回值的。这样可以保证View不是从Presenter拉去数据，而是有Presenter主动将结果推送给View。
7. Presenter对View的调用，应该仅通过接口。每个View都应该对应一个IView, Presenter只依赖IView，不依赖实现。这样可以在单元测试的时候Mock View。
8. View中除了IView中定义的方法之外都应该是非Public的。
9. 除了Presenter，禁止从其他的地方直接访问View。
10. IView中定义的方法应该根据use-case取一个具有业务含义的名称，像SetDataSource这样意义模糊的命名是不合适的。
11. IView中不要只定义方法，不应该定义属性。Presenter对View调用应该通过方法的调用，而不是Set Data。
12. 数据应该保持在Model中。
13. View中方法名不应该包含具体的控件名，这会导致Presenter知道太多的View的实现细节。
14. View中的方法名应该具有业务含义，这样代码更容易被理解和自描述。

个人观点

• 第4、5点说的是View怎么调用Presenter的方法，目的是View传递用户的请求给Presenter。个人的观点更为激进， 我觉得应该杜绝View对Presenter方法的调用。
  那么，View应该如何调用Presenter呢？没错，event。View一定是被用户触发了某个事件，才需要请求Presenter的，同时这个事件就是某一个业务。那么我们应该在IView中定义好相应的event，然后在Presenter中订阅相关的事件即可。
• 第11点， 个人觉得在IView定义属性也未尝不可。Presenter往View推消息当然是用方法更有语义。但是有的时候，Presenter收到某些来自View的请求的时候，我们同时也需要一些View上其他Data。
  也就是说，有的时候我们同时要对View获取或推送Data，那是不是可以考虑直接定义成属性呢？ 当然这是一种方式。
  如果严格执行第11点的建议，我们也可以用参数将Presenter需要的数据传递给Presenter。具体来说就是将就是通过event的EventArgs来传递，这是另一种方式。

原文：Design Rules for Model-View-Presenter
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 incorporates that the capabilities of WinForms views have become smart enough to lift some of the burdens previously 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 should 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 calls 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 would 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 should have a XxxView suffix: TaskView/ITaskView
2. All presenters should 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. Calls from the view to the presenter should be kept at an absolute minimum, and used for "event" type calls only: _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. Calls from 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, except 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 should 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 should be kept in the model, no data should exist only as properties of UI controls
13. The methods of the view interface should 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 process documents that 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 would write and publish some of these MVP design rules as custom FxCop rules.