ASP.NET WebForm MVP（三）- MVP模式应用总结
通过前面两篇文章，对MVP的基本概念以及简单的应用都有相应的介绍，那么接下来就主要总结一下这一年左右在ASP.NET WebForm中应用MVP模式的一些体会，很多东西看起来的确很美好，但当实际应用的时候往往还有很多问题需要考虑。
实践资料
把这点放在最前面，不是说MVP模式的资料少，随便搜一下还是有很多信息，但别开心太早，仔细看看这些资料就知道为啥我会这样说了，绝大部分都是在讲MVP模式的基本概念、基本应用之类，而且都不忽悠，真的都很基本，通过这些资料去了解下MVP模式还是可以，但作为学习资料或者框架选型的参考资料还是有些“难度”。真要去找点实践经验、应用开发指引之类的资料比较费时间，而且找出来真能够用上的也不多。
总的来说，我觉得实践指导资料对使用一门技术框架是非常重要的，就拿Python来说，Web框架可以说是百花齐放，但Django应该可以说是使用最多的了，但如果说它是Python里面最好的Web框架，估计马上会有很多人跳出来坚决反对，但为什么它能做到市场占有率最高？很关键的一点应该是：近乎完美的官方文档。
MVP模式的实践资料的缺乏作为框架选型时比较担心的因素，也成为后面学习、开发、培训等过程中最头疼的问题。
应用框架
在第一篇介绍MVP模式的时候提到了不少MVP模式的一些应用框架，没有把找到的全部列出来，去搜一搜还是比较多的，但仔细去看看这些能找到的框架，也许会让人很失望。有的做了一半就没人继续更新；有的一个框架做倒做出来了，但翻来覆去找点说明文档或者Demo真的难。但不外乎也有一些不错的框架，但毕竟时间精力是有限的，经过测试评估的框架中能让人放心用的不是太多。
应用框架最终是选择了ASP.NET Web Forms Model-View-Presenter (MVP)框架，在CodePlex有源代码可以下载，去年看是一直在更新，所以比较放心，给的Demo例子也通俗易懂，框架的扩展性也算还可以。可惜官方的东西都会有一定的风险，何况这些框架。在去年底更新过一个版本之后再无更新；发现一些BUG反馈过去但也没见回复；扩展性的确不错，可惜扩展之后总会有些让人抓狂的小问题。
整体来说，如果项目中需要使用MVP模式的方式不是很复杂，性能要求不是太高情况下，感觉可以考虑自己实现基本的应用框架，而且在一些已有的框架中还是有很多实现方式可以参考的，但做得太复杂的话容易出现一些未能考虑完全的细节问题。使用其他框架的话没有官方的支持，感觉风险还是比较大的，如果可以的话也可以考虑自己去维护扩展这些已有的框架。
开发难度
MVP模式简单点说就是可以将页面逻辑也业务逻辑，先不说一些更高级的目标，先想想怎么去区分页面逻辑和业务逻辑，听起来貌似不难，但真正去开发的时候真的够纠结的。
举个简单的例子，页面有一棵树需要去呈现，那么就需要获取数据，然后呈现。获取数据！呈现！这不是已经区分了页面的逻辑和业务逻辑？看起来是做到了，那获取数据是应该组织成“树结构对象”给页面呈现，还是获取“一般的数组对象”给页面逻辑去处理下然后呈现？
也许有人会问这些细节重要么？单个页面来说两种方式问题都不大，但是当在整个项目中之后，因为这些分离的“度”不同，会让项目中的程序“百花齐放”，也许这些程序过段时间除了上帝再没人能看懂了。
上面提到的分离就感觉已经让程序的开发和维护复杂了不少，再看看那些接口、事件、事件参数的定义等，如果页面简单还好，但稍微复杂的页面就是很可怕的文件数和类定义，维护起来也不是那么容易。
可能开发过程中会发现有些地方可以“偷懒”，如将View传递Presenter信息的事件参数省略，然后通过ViewModel进行传递（这样子和MVC的做法很类似），但事实最后告诉我们代价更加沉重。
最后如果再考虑高级点的目标，Presenter的重用、View接口定义的重用等，如果没有很全面的开发指引文档来约定的话，即使实现了这些目标，维护这些代码的成本和分离之后带来的部分可测试性两者比起来，感觉是得不偿失。可惜全面的指引文档还是是很难找到的东西，靠自己开发过程中去总结成本也不低！
单元测试
MVP模式通过分离页面逻辑也业务逻辑之后，使得业务逻辑部分（Presenter）可以进行单元测试，这也是使用MVP模式的主要目标，但其实可测性关键还是把握在程序员手中——关键还是分离的“度”。而且想做到测试的规划，甚至测试驱动开发，基本是不太可能，因为不管怎么分离，最基本的事件驱动方式的开发思想还是没有改变。
这样看来似乎程序的质量又回到了程序员手中，但也不完全是，关键还是需要指引文档来约定大部分通用的分离原则，使得大部分业务逻辑可以测试，提升大部分页面的质量，不过这类文档还需要自己开发过程中去总结完善，而且根据不同的项目可能还需要有一些相应的变化。
总结
通过上面的介绍，可以看到MVP模式在实际应用时候有不少的问题，有些问题通过开发实践，也能够找到相应的解决方法。总的来说对MVP模式在ASP.NET WebForm的实际应用体会主要有：
- MVP模式的确是不错的，但是模式也就是思想而已，要实际应用还有一段路需要走，而且这段路还是有比较大的风险的
- 不要觉得MVP模式的应用对程序员的要求比其他MVC之类的框架低，即使是在原有的事件变成模式基础上进行变成，但其他方面的要求还是很多
- 条件允许的情况下，可能自己实现MVP模式的应用框架比用其他半吊子的框架更加可靠，MVP模式的简单实现并不复杂
- 使用MVP模式进行开发时，对大部分通用页面应该有比较详细的开发指引，可以让程序看起来更加统一，也能够保证基本的可测试性