更多分层会做这项工作吗？

Question

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

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

上面的示例可能与实际业务需求相差甚远，但考虑到它，那么我想的是这个操作将有大约10个以上的服务。

当使用构造函数依赖时，拥有10多个构造函数应该是一件坏事，所以我认为重构它会完成这项工作。重构设计的一些例子：

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

项目金额验证过程已从提交者制作了4个图层：ISubmitter-＆gt; IValidator-＆gt; IItemValidator-＆gt; ItemAmountValidator。

我知道在Separation of Concern方面，我可以很容易地得到我需要的正确实现（例如：ItemAmountValidation）。但是在调试代码方面，不会更难跟踪它使用的验证类吗？由于构造函数注入是在实现中定义的而不是在接口中定义的？

考虑最糟糕的情况，当调试器不是开发人员时，只有最小的测试场景，根本没有文档。

Answer 1

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

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

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

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

Answer 2

  

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

是的，它可能会让你在调试时跳过更多的类。但是，这种设计允许您的代码进行测试（当然使用TDD），在练习TDD时，您必须比以前更少地调试代码。