对于SharePoint Developers来说，往往会过多的去关注SharePoint平台和工具，而把设计模式和代码的可测试性放在了一个较低的优先级。这并不是说SharePoint Developers对设计模式不感兴趣，而是缺乏在SharePoint平台下使用设计模式的经验。所以本篇Blog正如题目所示：探索MVP（Model-View-Presenter）设计模式在SharePoint平台下的实现。利用MVP设计模式，可以尽量让我们的项目分离关注点、易测试、可重用。在实现MVP时，我也会加入Repository和Service Locator这两种设计模式，Repository可以理解为一个仓储，相当于数据访问层（DAL），而Service Locator扮演了IoC角色，IoC类似一个工厂（容器），工厂内部注册了很多依赖关系，IoC容器正式使用这种依赖关系从而动态的注入（又称依赖注入）提供你所需要的实例，这样可以有效的实现解耦，即分离关注点。
MVP模式
在SharePoint平台下，如开发SharePoint Farm Solution，如果不对代码进行重构，往往会出现这样的代码:
很明显这样把所有的逻辑都杂揉在UI Logic，特别是在团队开发时，即不利于测试，也不利于分工协作。而且对于SharePoint而言，开发机性能若低，调试是苦不堪言的，其耗时难以想象。所以前期如能通过单元测试解决Bug，将大大的节约时间。幸运的是，MVP设计模式的出现，对于Web Part的开发，是非常适合的。MVP的特点是很好的分离了关注点，各司其职。把上图稍作更改如下所示：
可以看到的是UI Logic处理的业务逻辑交给了Presenter，而UI彻底解放了，只单纯的做显示层（View）。
Repository Design Pattern
从上图可以看出，Presenter并不是直接去访问SharePoint数据层( SharePoint List)，而是通过了一个Repository 去间接访问，而Repository Model 封装了数据层。
到这一步，看似完美，但实则还是在原地踏步。因为Presenter和Repository还是紧耦合着，这就好像负责Presenter的 A程序员必须要等负责Repository 的B程序员完成才能工作。
谁叫他们紧耦合在一起呢？
在团队开发中，我们需要的是互相独立，所以需要让负责Presenter的程序员可以使用MockRepository来做测试，这样就不会影响进度了，幸运的是，基于接口的设计，可以让我完成这个愿景。具体的实现如下：
SharePoint Service Locator Design Pattern
仔细分析上图，Presenter还是没有解耦，因为这必须要在Presenter中把某个Repository的实例创建出来，所以Presenter还是依赖了Repository这个项目程序集。这对测试没有好处，（正如前面所分析的那样，开发Presenter 的A程序员必须可以在单元测试里使用MockRepository来测试，而在真实的项目里使用B 程序员开发的AnyRepository）。
那么有没有一种方式能彻底将Presenter和Repository解耦呢？
当然有，如依赖注入，本篇博客介绍的是由Microsoft Patterns and Practices 专门为SharePoint开发的IoC容器：SharePoint Service Locator。