模型-视图-控制器 (MVC) 模式的核心是将 UI 功能划分成三个组成部分。模型表示您的领域的数据和行为。视图管理模型的显示并且处理与用户的交互。控制器协调视图和模型之间的交互。通过这样将本质上就难于测试的 UI 逻辑与业务逻辑分离开来，使得使用 MVC 模式实现的应用程序非常易于测试。在本文中，我将论述用于增强您的 ASP.NET MVC 应用程序的可测试性的最佳做法和技术，包括如何建立您的解决方案的结构、设计代码架构以便处理依赖关系注入以及使用 StructureMap 实现依赖关系注入。
建立您的解决方案的结构以便实现最高的可测试性
与每个开发人员都开始一个新的项目（即创建解决方案）相比，再没有更好的方式 来开始我们的讨论了。我将基于我在使用测试驱动开发 (TDD) 来开发大企业 ASP.NET MVC 应用程序方面的经验，论述用于规划您的 Visual Studio 解决方案的一些最佳做法。首先，我建议在创建 ASP.NET MVC 项目时使用空的项目模板。其他模板很适合于试验或创建概念证明，但它们通常会包含许多会让人分神且在真正的企业应用程序中不必要的干扰内容。
在您创建任何类型的复杂应用程序时，都应该使用 n 层方法。对于 ASP.NET MVC 应用程序开发，我建议使用在图 1 和图 2 中阐释的方法，其中包含以下项目：
- Web 项目包含所有特定于 UI 的代码，包括视图、视图模型、脚本和 CSS 等。该层只能访问 Controllers、Service、Domain 和 Shared 项目。
- Controllers 项目包含 ASP.NET MVC 使用的控制器类。该层与 Service、Domain 和 Shared 项目通信。
- Service 项目包含应用程序的业务逻辑。该层与 DataAccess、Domain 和 Shared 项目通信。
- DataAccess 项目包含用于检索和操作驱动应用程序的数据的代码。该层与 Domain 和 Shared 项目通信。
- Domain 项目包含应用程序使用的域项目，并且禁止与任何项目通信。
- Shared 项目包含可用于其他多个层的代码，例如记录程序、常量和其他常见实用工具代码。仅允许该项目与 Domain 项目通信。
图 1 各层之间的交互
图 2 解决方案结构示例
我建议将您的控制器放置于一个单独的 Visual Studio 项目中。有关如何轻松实现此建议的信息，请参见 bit.ly/K4mF2B 上的博客文章。通过将您的控制器放置于单独的项目中，您可以进一步将处于控制器中的逻辑与 UI 代码分离开来。结果就是您的 Web 项目仅包含真正与 UI 相关的代码。
在哪里放置您的测试项目 在哪里放置您的测试项目以及如何对这些项目进行命名十分重要。在您开发复杂的、企业级应用程序时，解决方案往往会变得相当大，因此，很难在解决方案资源管理器中定位代码的特定类或部分。将多个测试项目添加到您的现有代码库中只会导致在解决方案资源管理器中进行导航更复杂。我强烈建议您将测试项目与实际的应用程序代码从物理上分隔开来。我建议将所有测试项目都放置于解决方案级别的 Tests 文件夹中。在单个解决方案文件夹中定位您的所有测试项目和测试将会显著减少默认解决方案资源管理器视图中的干扰内容，从而允许您轻松地定位您的测试。
发表回复