ASP.NET MVC框架（第一部分）
| 象这样分开Controller和View有什么好处呢？为什么不把它们放在同一个类里呢？象这样分割应用的主要动机在于帮助你加强 应用/数据逻辑与你的界面生成代码间的分离。这可以在隔离你的界面显示逻辑的情形下，极大地方便你单元测试你的应用/数据逻辑。它还有 助于使得你的应用更好维护，因为它妨碍了你无意中把应用/数据逻辑加到你的视图模板里的可能。
在实现我们ProductsController类的三个控制器action方法时，我们将根据进来的URL参数值从数据库中获取适当的模型对象，然后选择一 个“视图”组件来显示适当的HTML响应。我们将使用Controller基类的一个RenderView() 方法来指定我们想要使用的视图，以及明 确地把我们要视图在显示响应时使用的特定数据传入该方法。 下面是我们的ProductsController实现的最终结果：
注意，我们的action方法的代码行数目很小（每个方法只有2行），部分原因是因为URL参数分析逻辑完全是由MVC框架为我们做的（给我们 省了很多行代码），还有部分原因是因为产品浏览场景从业务逻辑的角度来说相当简单（涉及的action方法都是只读的显示场景）。 但总的来说，你经常会发现你有的都是些有时被称为“瘦控制器”的东西，即控制器方法充满了相当简短的action方法（少于10 行代码）。这经常是好的迹象，表明你非常干净地封装了你的数据逻辑，也非常好地分隔了你的控制器逻辑。 单元测试ProductsController 你也许会感到惊奇，我们要做的下一步居然是测试我们的应用逻辑和功能。你也许会问，这怎么可能呢？我们还没有实现我们的视图呢，我 们的应用目前并不显示一个HTML tag。其实呢，使得MVC方法有魅力的部分原因就是我们可以完全独立于视图/Html生成逻辑来测试Controller 和Model 逻辑。在下面你将看到，我们甚至可以在创建视图前单元测试这些对象。 为单元测试我们在编写的ProductsController类，我们将往测试项目里加一个ProductsControllerTest类，这个测试项目是在我们使用 Visual Studio创建我们的ASP.NET MVC应用时，默认添加到我们的解决方案里的：
然后我们将定义一个简单的单元测试，测试我们的ProductsController的 Detail action方法：
ASP.NET MVC 框架是特地设计来促成轻松的单元测试的。框架中的所有的核心API和契约都是接口，提供了大量的扩展点以促成轻松的对象 注入和定制（包括使用象Windsor, StructureMap, Spring.NET, 和ObjectBuilder这样的IOC容器的能力）。开发人员将能够使用内置的mock类 ，或者使用任何.NET 类型mock框架来模拟他们自己的MVC相关对象的测试版本。 在上面的单元测试中，你可以看到一个例子，我们是如何在调用 Detail() action 方法之前，往我们的ProductsController里注入了一个 伪（dummy）“ViewFactory”实现的。这么做的话，我们就覆盖了默认的ViewFactory，否则的话，默认的ViewFactory会创建和显 示我们的视图。我们可以使用这个测试ViewFactory实现来做隔离，只对我们ProductController的Detail action的行为进行测试（而不必调用 实际的视图来做测试）。注意我们是如何在Detail() action方法被调用之后，使用了三个 Assert 语句来核实该方法的正确的行为确实发生了 （具体地说，该方法获取了正确的Product对象，然后将它传给了适当的视图）。 因为我们可以mock和模拟MVC框架中的任何对象（包括 IHttpRequest 和 IHttpResponse 对象），你不用再在web服务的环境里运行单元测 试，我们可以在常规的类库里创建我们的ProductsController对象，然后对它直接测试。这可以极大地加快单元测试的运行速度，以及简化对 它们的配置和运行。 如果我们使用 Visual Studio 2008 IDE，我们还可以轻易地跟踪我们运行测试的结果（这个功 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
