更多分层会完成这项工作吗？

Question

考虑有一个非常复杂的业务需求，需要在启动操作时执行多个业务逻辑步骤。例如，当用户提交请求时，需要执行的步骤是：

• 验证数据
  • 验证请求是否已存在
  • 验证用户是否存在
  • 验证用户是否有足够的财务金额来提交请求
  • 验证用户是否可以立即发布请求
  • 验证是否有请求的项目
  • 验证请求的项目是否有效
  • 验证项目没有负金额
  • ...（进一步验证）
• 将数据存储到存储库
• 向用户或相关方发送电子邮件
• ...（可能需要完成其他步骤）

上面的例子可能与真正的业务需求相去甚远，但考虑到它是，那么我想这个操作将有大约 10 多个服务。

在使用构造函数依赖时，拥有 10 个以上的构造函数应该是一件坏事，所以我认为重构它就可以完成这项工作。重构设计的一些说明：

ISubmitter(IValidator, IRequestRepository, INotification)
IValidator(IRequestValidator, IItemValidator)
IRequestValidator(IRequestRepository, IUserValidator, IItemExistValidator)
IUserValidator(IUserRepository, IUserFinancialValidator, IUserPublisherValidator)
IItemValidator(IItemRepository, IItemAmountValidator)
... // maybe more

项目金额验证流程从提交者做了4层：ISubmitter->IValidator->IItemValidator->ItemAmountValidator。

我知道就关注点分离而言，我可以轻松获得所需的正确实现（例如：ItemAmountValidation）。但是在调试代码方面，跟踪它使用哪个验证类会不会变得更加困难？既然构造函数注入是在实现中定义的，而不是在接口中定义的？

考虑最坏的场景，当调试者不是开发者时，只有最低限度的测试场景，根本没有文档。

Answer 1

你说的逻辑属于不同的层，但是需要注入到你的应用层。我要做的是注入执行任务所需的组件，例如执行请求的命令处理程序；一个负责验证输入的验证器，一个处理数据逻辑的存储库，以及一个发送邮件的 Mailer 组件（或服务）。

这一切都是为了将​​职责放在正确的组件中。构造函数注入是一个很好的选择，它在灵活性、可测试性方面为您提供了很多优势，并且使您的代码易于理解。

就调试而言，我不认为您需要做的更多努力应该成为不以模块化方式构建代码的理由。只要设置正确的断点就可以了。

也许http://tinyurl.com/d99w8rl 可以为您提供更多见解。

Answer 2

但就调试代码而言，跟踪哪个代码会更难吗？ 它使用的验证类？由于构造函数注入定义在 实现而不是在接口中？

是的，它可能会让你在调试时不得不跳过更多的类。但是，这种设计允许您的代码被测试（当然使用 TDD），并且在练习 TDD 时，您将需要比以前少得多的调试代码。