MVP+WCF+三层结构搭建项目框架

MVP+WCF+三层结构搭建项目框架（上）

　最近，我一直在重构之前做的一个项目，在这个过程中感慨万千。原先的项目是一个运用了WCF的C/S系统，在客户端运用了MVC模式，但MVC的View、Model耦合以及WCF端分布式欠佳等问题让我有了重构的想法，经过了一段时间的改造，逐渐形成了MVP+三层结构+WCF的面向服务的程序架构。在这里我把我的想法写成了一个例子，供大家参考。

　　在正式开始讲解之前，我必须得感谢Artech、代震军等诸多大虾，他们的文章给了我很大的启发。

　　我写的这个例子是关于博客管理的，逻辑很简单，就是用户发表文章、发表评论，管理员可以对用户进行管理。让我们先从MVP的运用开始讲起。

　　MVP与MVC的选择

　　关于MVP和MVC，我只谈谈在重构过程中的看法。在经典的MVC中，View会通过Controller调用Model中的方法，Model被更新后会立即通知View，因此View与Model还是存在一定程度的耦合的，Controller也只是作为一个简单的消息分发器，View与Controller也紧紧的贴合好像是一个整体。而在MVP中，Presenter代替Controller而出现，成为View与Model解耦的关键，在MVP中，Presenter掌管大权，View的请求提交给Presenter，由Presenter调用Model，Model更新后的状态再返回给Presenter，由Presenter控制View进行相应的显示。如此，Model与View被完全解耦，View与Controller也形成了单向依赖。MVC与MVP可以说各有特点，但我更倾向于MVP。

　　关于MVC和MVP，给大家看这两张图就很明白了。对于刚接触MVP的朋友可能不知道View、Presenter和Model中具体该实现哪些东西，我会在用实例讲解的时候告诉大家我的想法。

View Code

　　这是一个用于处理User业务逻辑的接口，其中使用到的User类就是DTO中的User实体。Model中把接口公开出来供Presenter调用就可以了，Note和Comment的代码也类似，P-M之间的交互还是比较简单的。

　　OK，设计完Model，我们再来看看界面如何呈现，我的想法如图所示：

IUserControlView
IGridView
　　实现代码如下：

View Code
　　View实现代码的细节我就不贴了，在文章最后会提供示例的下载链接。

　　需要注意的是，View既然是针对抽象设计，接口中就不能暴露任何UI实现的细节。

　　现在，再来看看Presenter如何设计，一般来说一个View就有一个相对应的Presenter来控制，Presenter代码如下所示：

IGridPresenter

IUserControlPresenter

　　Presenter对View的引用是单向的，View不知道哪个Presenter在用它，View也无法访问到Presenter。我们让Presenter订阅View中的事件以响应View的请求。View是被动的，需要由Presenter控制，因此在Presenter实例化的时候同时实例化相应的View。

　　IGridPresenter的实现代码如下所示：

IGridPresenter Realize

　　IUserControlPresenter的实现代码如下所示：

IUserControlPresenter Realize

　　初始化加载所有用户信息的流程是这样的：当UserControlView加载时，UserControlPresenter随之响应并调用UserModel中的GetAllUsers方法。UserControlPresenter获取到数据后，再调用GridPresenter中的ShowUsers方法，将查询的数据绑定到GridView上，这时便看到了数据。在这个过程中，View提交请求是通过事件响应实现的，只要涉及到与数据相关的请求都必须要提交到Presenter中，由Presenter来决定下一步该做什么，View中则不能包含任何与数据相关的业务逻辑。从这个流程中我们也可以看到Presenter的掌控地位，他属于指手划脚的那类人，只是在告诉别人需要做什么，但自己却不会亲自动手。

　　大家可能注意到了，我把UserControlView中的Initialize方法公开在接口中，并没有在UserControlView构造时执行，这是因为UserControlView依赖于一个抽象的GridView，在构造时GridView还没有被注入，显然在这个时候初始化会出现未将对象引用设置到对象的实例的异常。因此我把UserControlView的初始化工作交给Presenter处理，将初始化的时机延后到所有依赖注入完成，而View不会主动执行Initialize。

　　IUserControlPresenter已经是最顶层的Presenter了，它只需要公开出接口供Main调用启动程序即可。

　　我感觉，P-V交互是MVP模式运用的重点，本人水平有限，文中疏漏或讲解不到位的地方还请大家谅解。关于MVP，大家可以看看Artech和代震军的文章，你们会学到很多，还有一篇关于MVP的14条规则的文章也强烈推荐。

　　这篇文章是关于MVP运用的，下面我会介绍我是如何把WCF服务端加入进来的，以及我对三层结构运用的心得。

　在上篇文章中，我对如何在项目中如何运用MVP谈了自己的看法。在本文，我将会把WCF服务端加入进来，以面向服务的角度完善我的程序。

　　胖客户端与瘦客户端的选择

　　C/S模式的程序一般会有两种形式，一种是瘦客户端(Thin Client)形式，即客户端仅处理UI界面的交互，把所有和数据相关的业务逻辑都放在服务器。另一种是胖客户端(Rich Client)形式，即客户端不仅要处理UI界面的交互，而且要完成定制业务逻辑规则的工作。Thin Client形式通常会被认为是B/S模式，毕竟浏览器可以说是最瘦的客户端了。但随着云技术的发展和对分布式要求的不断提高，传统的C/S模式也在力求使客户端轻量化，这样做的好处是更有利于业务规则的复用，将业务逻辑集中在一处也更有利于维护。Thin Client和Rich Client各有各的优点，各有各的用处，在本文的例子中更适合使用Thin Client形式。

　　Well，让我们回头看看我上篇文章中的例子。上文中的例子是个很典型的胖客户端，而在我们运用了MVP之后，获取数据的业务逻辑已经被完全隔离，在我划分的几个项目中，Model就是用于获取数据及处理业务逻辑的地方，因此我要把它从客户端中移出，把Model整体移植到WCF服务器。同时我们也要把DTO移植到服务端，因为他是数据的载体，服务端和客户端都需要引用，而且必须统一。

　　将Model移植到服务端

　　WCF服务器的基础知识我就不赘述了，对这方面不了解的朋友可以查阅相关书籍，园子里也有不少好文章。

　　我在服务端建了一个BlogService项目作为启动服务的入口，如图所示：

服务契约

　　BlogService项目中的ServiceManager类是用于管理服务的，它的代码如下所示：

ServiceManager

　　只要在启动程序时执行OpenAllService()，便可以启动服务。

　　在客户端使用WCF服务时我运用了Channel Factory的形式。不了解的朋友可以查阅相关资料，服务端运行结果如图所示：

ServiceCollection

　　客户端启动时先执行LoadServer()加载服务，然后调用服务时只需要这样做：

调用服务示例

　　客户端运行界面如图所示：

View Code

　　再举一个例子，假设有一个删除用户的操作，要求删除用户时将用户的文章和评论一并删除。因此，这个删除用户操作其实包含了删除评论、删除文章和删除用户三个操作。那么，这个业务逻辑就不应该出现在UserBll中，因为它同时涉及到了评论、文章和用户三张表，我们需要把这个逻辑放在更上层的UserGroup中，代码如下所示：

Delete User

　　至此，我对三层结构运用的理解就讲完了，希望对大家有所帮助。

　　由于本文主要是阐述搭建架构上的思想，因此文中的例子有很多地方做的并不是很好，例如在服务端的异常处理就很业余，大家可以参考Artech写的将EHAB与WCF结合的异常处理方式，感觉很不错。

　　关于MVP、WCF和三层结构的运用，也许每个人都有不同的理解，我在文章中提到的论断是我自己的看法，并不一定就是完全正确的，有许多还需要推敲。写本文的目的旨在于给大家一个参考，大家有什么意见或者建议都可以拿出来讨论，一个人的思想毕竟是有限的，我们需要集思广益。

　　大家可以到这里下载文中的例子 http://files.cnblogs.com/yanchenglong/Blog.rar

编程思想

MVP+WCF+三层结构搭建项目框架（下）

posted @ 2012-03-19 08:48 Charles Yan 阅读(661) | 评论 (5) 编辑

MVP+WCF+三层结构搭建项目框架（上）

posted @ 2012-03-19 08:47 Charles Yan 阅读(846) | 评论 (4) 编辑

由DIY想到的面向对象思想

posted @ 2012-01-28 11:10 Charles Yan 阅读(1467) | 评论 (13) 编辑