Mikel
[转载]基于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中的路由规则是必不可少的。
附：源代码
