组织ASP.NET MVC解决方案

Question

我已经开发了几个月的大型ASP.NET MVC 3应用程序。直到项目后期才意识到我的控制器是巨大的！这些控制器的部分问题是巨大的，我无法对它们进行单元测试。

我已经将控制器的职责分为四个任务（在我看来）：

• 导航
• 将ID转换为数据对象
• 构建展示视图模型
• 通用商业逻辑

由于某些业务逻辑是跨客户端和服务器端代码共享的，因此将它与视图模型构建器逻辑混合是没有意义的。因此，我立即看到至少需要两个项目：查看模型构建器和通用业务逻辑。

我意识到导航应该是控制器的责任，因此逻辑保留在MVC项目中。

关于哪个项目应该负责将ID转换为数据对象，我有点不知所措。最初，我已将此作为业务类/视图模型构建器类的职责。但是，我想我希望这些类能够与完全构造的对象一起工作。所以，我不确定这个转换应该在代码中的哪个位置发生。在我进行转换的地方似乎并不重要，代码变得重复。我一直在考虑在执行这些转换的相应项目中创建适配器，然后调用实际的业务类/视图模型构建器类。

• 有没有人在一个已经超越单个项目的ASP.NET MVC项目中工作过？
• 逻辑如何分解以保持控制器的大小并保持代码可测试？

Answer 1

  

  
• 有没有人在一个已经超越单个项目的ASP.NET MVC项目中工作过？
  

是

  

  
• 逻辑如何分解以保持控制器的大小并保持代码可测试？
  

按putting controllers on a diet。