基于MVC框架+IOC+Rhino Mocks的一个简单项目介绍

    现在不管是企业还是科研机构，几乎所有的项目开发都是遵循一定的框架，将经过实践证明过的开发框架和开发模式借鉴使用无可厚非，但难免会遇到某些功能实现或者基于某种考虑当前的开发框架无法达到这样的目的。这时我们就会考虑不同技术的融合。

我们现在正在开发的平台项目正是借鉴了这样的思想，我们的平台项目首先整体的开发框架使用了AspNet MVC框架；其次数据访问层套用了CommunityServer的开发框架，其中融合了Provider模式和传统的三层架构；而在业务逻辑层处理中，为了保证代码的可重用性以及可扩展性，我们引入了依赖注入（DI）；最后，在单元测试模块中我们使用了Rhino Mocks作为我们的测试框架。

（一）AspNet MVC框架，所谓MVC其实就是分别代表三个单词Model、View和Controller。了解他们分别的含义，我们就从Asp.Net页面的处理机制谈起。

一般来说，一个Asp.Net页面通常要处理一下事情：1. 因为最后展示的都是页面，所以我们要得到在页面上展示需要的数据，也就是Model。2. 在页面的Page_Load（页面加载）方法中为我们的页面控件绑定数据，涉及到这些业务逻辑的工作（即获取数据和绑定数据的工作）都是在Conotroller中完成的。3. 也就是我们看到的.aspx页面，不同的是这些页面都是没有后台.cs代码类的。

接下来我们需要明白在MVC中Web请求的处理流程，用户通过Web浏览器向服务器发送一条url请求，这里请求的url不再是xxx.aspx格式，而是http://HostName/ControllerName/ActionName/Parameters的格式。这个请求被ASP.NET MVC的路由映射系统截获（路由映射可以在Global.asax中配置）。路由映射系统按照映射规则，解析出控制器名ControllerName，Action名ActionName和各个参数Parameters，然后，寻找Controllers目录下的ControllerNameController.cs这个控制器类，默认情况下，系统总是寻找Controllers目录下的“控制器名+Controller”这么一个类，然后，找寻这个类下与ActionName同名的方法，找到后，将Parameters作为参数传给这个方法，而后Action方法开始执行，完成后返回相应视图，默认情况下，会返回Views目录下与ControllerName同名的目录下的与ActionName同名的aspx文件，并且将ViewData传递到视图。ViewData中一般包含了控制视图显示的控制量以及视图显示需要的数据，如图1所示。

（二）CommunityServer的开发框架

1. 三层架构，即数据访问层、业务逻辑层和表现层。这样开发的系统简洁并且易于理解。

2. Provider模式，关于Provider模式我们已经非常熟悉，这是我们处理数据访问层逻辑和业务逻辑层逻辑经常会采用的方式，实现Provider模式需要4各类：基础类（即对应数据库中相应表的类）、工具类（即在基础类基础上写的函数类）、接口类（即工具类中会调用接口类中的方法）、实现类（即实现接口类中的方法）。例如下面的例子：User(基础类，对应数据库中的User表)-->Users（工具类，包含User的方法，比如GetUser方法）-->UserDataProvider(接口类，该类中声明了GetUser方法)-->SqlUserDataProvider（实现类，该类实现了UserDataProvider类中声明的GetUser方法）。

3. 需要注意的是构建三层架构使用Provider模式时一定要谨慎，鼓励大家自己尝试一下，会发现张口容易动手难。

（三）依赖注入。关于依赖注入，大家可以看我的前一篇博客--也来谈谈依赖注入模式。希望会对大家有帮助。本着测试先行的原则，引入依赖注入不仅使代码复用性加强，而且便于测试。在我们平台项目中，我们使用了Castle IoC。

（四）Rhino Mocks单元测试框架。在平台项目的测试中，由于开发框架的特殊性以及其中的三层架构用到了几种技术，所以为了测试全面，我们需要将测试分为几层来测试。总体来看我们这个项目的大体构造流程如下所列：基础类-->工具类-->接口类-->实现类-->controller-->View。因而我们在测试时将其分成工具类的测试（即函数的测试）以及Controller层业务逻辑的测试两部分。需要注意的是这两部分的关注点是不一样的，在工具类的测试部分，我们关注的是函数实现业务逻辑的正确性，因此我们会忽略数据访问层而专注于测试函数功能是否能够实现；在Controller层业务逻辑测试部分，我们关注的是在controller层处理的业务逻辑能否在view层返回给我们需要的数据，因此我们关注的是controller类里面的业务逻辑实现，而我们会刻意忽略其中调用的函数的实现环节。

（五）最后附上一个简单的实例说明：这个实例MySingleCase就是一个最简单的MVC框架+CommunityServer开发框架+Provider模式+IOC+Rhino Mocks测试框架的应用，其模式和我们现在正在开发的平台项目一致。

其中MysingleCase.Components中放置的是全局类以及公共类，包括CSCache.cs缓存类、CSConfiguration全局配置类、DataProvider（Provider基类）、IoC（依赖翻转的公共操作类）、WindsorServiceLocator.cs（服务定位器处理类）等。

MysingleCase.Models中放置的是项目中用到的用户自定义的基础类，包括基础类、工具类、接口类。其中Service中放置的就是使用依赖注入时需要的接口类。

MysingleCase.Web项目中就是具体的MVC框架的使用。Controllers文件夹下面是所有的Controller，对应于每一个Controller中的ActionResult的表示层都放在Views文件夹下的相应路径下。而其中的IoC文件中的ContainerBuilder.cs类负责Controller以及需要使用依赖翻转的所有类的注册。别忘记我们使用MVC的必要条件也就是Global.asax中的路由规则是必不可少的。

附：源代码