博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
探索MVP(Model-View-Presenter)设计模式在SharePoint平台下的实现
阅读量:7237 次
发布时间:2019-06-29

本文共 8871 字,大约阅读时间需要 29 分钟。

阅读目录

 

对于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。

什么是IoC容器

传统的控制流,从客户端创建服务时,必须指定一个特定服务实现(并且对服务的程序集添加引用),IoC容器所做的就是完全将这种关系倒置过来(倒置给IoC容器),将服务注入到客户端代码中,这是一种推得方式(依赖注入)。术语"控制反转",即客户放弃代码的控制,将其交给IoC容器,也就是将控制从客户端代码倒置给容器,所以又有人称作好莱坞原则"不要打电话过来,我们打给你"。实际上,IoC就是使用IoC容器将传统的控制流(客户端创建服务)倒置过来,将服务注入到客户端代码中。

总之一句话,客户端代码能够只依赖接口或者抽象类或基类或其他,而不关心运行时由谁来提供具体实现。

使用IoC容器如SharePoint Service Locator,首先配置依赖关系(即当向Ioc容器询问特定的类型时将返回一个具体的实现),所以这又叫依赖注入。

MVP在项目中的实践

有了上面的分析,那么就来设计漂亮的代码:

  • 模块化代码
  • 松耦合,无依赖
  • 代码重用
  • 独立的单元测试
  •  首先创建IVew,单纯的给UI界面"取"数据和"显示"数据
复制代码
public interface IEmployeeView    {        string Country { get; }        IEnumerable
EmplyeeList { set; } bool NotEmployeesFoundMessageVisible { set; } }
复制代码
  • 接着WebPart实现IView
  • 接着对BaseRepository的设计
复制代码
public abstract class BaseRepository
{ protected SPWeb _web; public BaseRepository() { } public BaseRepository(SPWeb web) { _web = web; } protected IEnumerable
GetEntities(SPListItemCollection items) { List
list =null; if (items.Count>0) { list = new List
(); foreach (SPListItem item in items) { list.Add(GetEntity(item)); } } return list; } protected abstract T GetEntity(SPListItem item); }
复制代码
  • 正如前面分析的那样,基于接口的设计能更好的做单元测试,所以创建IRepository
public interface IEmployeeRepository    {        IEnumerable
GetEmployeeByCountry(string country); }
  • 实现Repository
  • 因为Presenter与Repository彻底解耦,故在Presenter中,根据构造函数动态注入View和Repository
  • 关键点来了,在Feature中向SharePoint Service Locator依赖注册(IRepositoy/Repositoy)
复制代码
public override void FeatureActivated(SPFeatureReceiverProperties properties)        {            SPSite site = properties.Feature.Parent as SPSite;            IServiceLocator serviceLocator = SharePointServiceLocator.GetCurrent(site);            IServiceLocatorConfig serviceLocatorConfig = serviceLocator.GetInstance
(); serviceLocatorConfig.Site = site; serviceLocatorConfig.RegisterTypeMapping
(); } //Uncomment the method below to handle the event raised before a feature is deactivated. public override void FeatureDeactivating(SPFeatureReceiverProperties properties) { SPSite site = properties.Feature.Parent as SPSite; IServiceLocator serviceLocator = SharePointServiceLocator.GetCurrent(site); IServiceLocatorConfig serviceLocatorConfig = serviceLocator.GetInstance
(); serviceLocatorConfig.Site = site; serviceLocatorConfig.RemoveTypeMappings
(); }
复制代码
  • 注意这个Feature 的Scope必须在在Site Level之上(建议在Farm),因为有可能用户在有权限Deactivate Feature
  • 根据依赖关系动态获取实例
复制代码
private EmployeePresenter _presenter;        public VisualWebPart1()        {            IServiceLocator serviceLocator = SharePointServiceLocator.GetCurrent(SPContext.Current.Site);            IEmployeeRepository employeeRepository = serviceLocator.GetInstance
(); _presenter = new EmployeePresenter(this, employeeRepository); }
复制代码

 总结

至此,探索MVP(Model-View-Presenter)设计模式在SharePoint平台下的实现,已经全部结束了,在这个基础架构上还可以继续优化,如DataMapper等。相信构建高效清晰整洁的代码是每个程序员所追求的,你不得不佩服国外大神们总结的设计模式是多么的精妙,或许怀着敬畏的心才能慢慢体会其中的奥秘。

 

本博客为 原创,基于 发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 (包含链接)。如您有任何疑问或者授权方面的协商,请给我留言。
分类: , ,
标签: ,
本文转自木宛城主博客园博客,原文链接:http://www.cnblogs.com/OceanEyes/p/mvp-design-pattern-in-sharepoint.html,如需转载请自行联系原作者
你可能感兴趣的文章
我用iPad / iTouch来做什么
查看>>
php的mysql_insert_id()返回值问题
查看>>
css属性兼容
查看>>
Hadoop源码分析之心跳机制
查看>>
第三章初步了解函数
查看>>
[转] PHP常见的两个面试题
查看>>
asp.net MVC3 View视图
查看>>
利用Nginx搭建http和rtmp协议的流媒体服务器[转]
查看>>
面试笔试
查看>>
用CleanMyMac误删了语言包怎么办
查看>>
Java读写Word文件常用技术
查看>>
Android - View绘图原理总结
查看>>
按键精灵手机版监控像素变换点击脚本
查看>>
maven jar包上传到服务器
查看>>
SecureCrt退出全屏
查看>>
扩展功能==继承?
查看>>
HDU 4355 Party All the Time(三分|二分)
查看>>
算法笔记_223:打印回型嵌套(Java)
查看>>
Linux环境thinkphp配置以及数据源驱动改动
查看>>
C语言之基本算法11—牛顿迭代法求平方根
查看>>