ASP.NET MVC老旧项目代码架构重构与单元测试方案咨询

核心思路 #

先把控制器里的复杂业务逻辑拆出来，遵循「关注点分离」原则——控制器只做请求接收、参数校验、调用业务逻辑、返回响应这几件事，复杂业务交给专门的类处理，这样才能从根本上提升代码的可读性、复用性和可测试性。

具体疑问解答 #

1. 是否需将业务代码迁移至独立文件？
   必须要。2000行的控制器完全是反模式，把业务逻辑抽成独立的业务类（比如EmailService），每个类只负责单一功能，控制器只做调用。这样控制器代码会骤减，后续维护、改bug都方便，也能单独给业务类写单元测试。

2. 是否应使用类库项目（Classlib project）？
   建议用，你设想的结构可以优化得更合理：

• 主项目MyMainProject（ASP.NET MVC）：保留Controllers、Views、ViewModels（专门放视图绑定的模型，别和业务模型混）、AppCode（遗留代码可以慢慢迁移）。控制器通过依赖注入调用业务服务的接口，而不是直接new类，这样方便换实现或者写测试时打桩。
• 类库项目按职责命名，比如MyMainProject.Core（放领域模型、核心业务规则、基础接口）、MyMainProject.Services（放具体业务服务，比如EmailService）；如果业务简单，先从MyMainProject.Business开始，里面按功能分文件夹（Email、Order等）。
• 单元测试项目MyMainProject.UnitTests：按被测模块建目录，比如ServicesTests、ControllersTests。

3. 若使用类库项目，是否需为主项目和类库项目分别创建单元测试项目？
   不需要，一个单元测试项目足够。架构上按被测项目划分目录就行：

• 在MyMainProject.UnitTests下建CoreTests、ServicesTests、ControllersTests子目录，对应类库和主项目的模块。
• 测试类命名用「被测类名+Tests」，比如EmailServiceTests、EmailControllerTests，一目了然。

4. 是否可创建多个类库项目？
   完全可以，甚至推荐按职责拆分多个类库，比如：

• MyMainProject.Core：存放领域模型、核心业务规则、基础接口，是整个项目的核心，不依赖其他类库
• MyMainProject.Services：实现业务逻辑，依赖Core
• MyMainProject.Infrastructure：存放数据访问（比如EF上下文）、外部API调用、第三方服务封装等，依赖Core
  这样拆分后每个类库职责单一，耦合度低，后续扩展新功能或者替换某部分实现都更灵活，也能单独对每个类库做测试。

标签建议 #

这个问题应该归类到clean-code标签，同时加上asp.net-mvc、refactoring、unit-testing标签会更精准，因为既涉及代码整洁实践，也包含MVC项目重构和单元测试的内容。

内容的提问来源于stack exchange，提问作者Aj.son