当我们谈论MVP的时候，我们在说些什么-前篇
前言
我的日常工作中很大一部分的精力要用来是维护一个从公司成立那天就存在的一个Winform客户端程序。技术债务已经欠了十几年，项目组成员来来去去，各种编码风格在各种需求的追赶下，不停地往里堆砌代码，项目的代码已经臃肿不堪，UI逻辑与业务逻辑罗织在一起，技术架构落后，还是十余年前的面向过程的面条式风格。在我看来，整个项目都已经到了最危险的时候，这笔债已经不能不还。
规划
凡事预则立不预则废，对在自己能力范围内，把可以预见的事情想清楚，设定好具体的目标，一步一步前进。这是我的基本原则。本次重构一下目标如下：
- 统一编码规范
- 分离UI逻辑和业务逻辑（MVP）
- 抽象业务逻辑，使其能最大化复用（面向接口）
- 可以供其他业务系统重用的逻辑服务化(采用Restful Api或者Wcf）
- 业务对象，必须自治，职责单一
- 外部资源的依赖采用注入的方式进行，目的也是为了能够实施单元测，能够Mock依赖
- 建立单元测试
MVP
MVP架构图
- 为什么要选择MVP，以及MVP的架构说明
- 选择MVP模式的目的是要解耦UI逻辑和业务逻辑。
- Model不是仅仅来承载数据的实体对象，而是领域对象，每个Model应该某一种业务的抽象，它应该职责单一并且具有自治性。
- Presenter是一个系统的中枢，它决定了系统是如何运转的，何时该调用一个Model或者多个Model来完成用户的请求，并且决定何时将结果呈现给用户。
- View是用来和用户交互的，也就是通常意义上的UI。它负责将用户的Request传递给Presenter，并响应Presenter将结果呈现出来。
- View会根据业务场景被抽象为IView, 由IView代表View与Presenter进行交互。Presenter不关心具体的View，View与Presenter都是基于IView接口进行编程的。这样就实现了UI逻辑与业务逻辑的解耦，并且由于不依赖具体的View，所以我们也同时获得了可以Mock View从而进行单元测试的优势。
- 从代码的组织架构是来说，View根本不需要知道Model的任何细节，对Model的调用都是通过Presenter进行决定的，Presenter也不需要知道具体的View的实现，只需要依赖IView接口即可。这样View层完全不必引用Model层，从物理上也实现了UI与业务的解耦。
黑话MVP
如果把MVP作为一个有组织讲纪律的江湖社团，那么Presenter则是这个社团当之无愧的的大哥。View只是这个社团的马仔，马仔的意义就是与外界打交道，然后把各种消息汇报给社团大哥，并接受大哥的指挥。Model则是大哥身后的各种资源。
例如下面的场景：
马仔收到外面的消息说，有人要打砸MVP社团旗下的王牌夜总会。
收到这个消息的马仔自然是要将消息汇报给大哥的：“大哥，我最近收到消息，有人打砸我们的夜总会，你看怎么办？要我做什么，请大哥吩咐！”。
大哥终归是大哥，做任何事情都是要经过考虑的，该动用哪些资源，不该动用哪些资源，何时动用都是要经过深思熟虑的。大哥收到马仔的汇报后，并不动声色，只是淡淡地给马仔说：“你先下去吧，我需要思考一下人生。”
大哥话是说思考人生，手里的动作可没有消停，他马上通知了负责王牌夜总会的头牌，让他调集一下人手；并且打了电话了给军火走私的好兄弟，让他帮忙准备一批武器。
大哥好累，但总归是协调好了各种资源，然后他召见了马仔：“小马啊，你放出风去，我们王牌夜总会最近人手不够了，要收点小弟啊。”
欲情故纵手段还是有的，先示敌以弱，然后一网打尽，大哥的如意算盘打得真是响啊。
总结：这就是MVP的交互流程。V将Request转交给P，然后又P去调用各种M来完成这个Request，最后P把结果告诉V。
错误的姿势是: V得到一个Request，然后V对P说，我知道该调用哪个M，你去调用吧，掉了告诉我结果。这是错误的做法，你试试看，大哥会不会保证不打死你。因为这会导致V与M的耦合，与我们使用MVP的初衷想背离，P也不再是Presenter而是Proxy。
下回分解
下一篇会介绍实施MVP的一些原则，并用代码来一步步演示MVP是如何实施的。
