Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/design-patterns/2.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181

Warning: file_get_contents(/data/phpspider/zhask/data//catemap/0/azure/12.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Design patterns 更多的分层是否可以完成这项工作?_Design Patterns_Architecture_Dependency Injection - Fatal编程技术网

Design patterns 更多的分层是否可以完成这项工作?

Design patterns 更多的分层是否可以完成这项工作?,design-patterns,architecture,dependency-injection,Design Patterns,Architecture,Dependency Injection,考虑到有一个非常复杂的业务需求,在启动操作时需要执行几个业务逻辑步骤。例如,当用户提交请求时,需要执行的步骤是: 验证数据 验证请求是否已存在 验证用户是否存在 验证用户是否有足够的财务金额提交请求 验证用户是否可以立即发布请求 验证是否存在用于请求的项目 验证请求的项目是否有效 验证项目是否没有负金额 。。。(进一步验证) 将数据存储到存储库 向用户或相关方发送电子邮件 。。。(可能还有其他步骤需要完成) 上面的例子可能与实际的业务需求相去甚远,但考虑到这一点,我认为这个操作将有大约1

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

  • 验证数据
    • 验证请求是否已存在
    • 验证用户是否存在
    • 验证用户是否有足够的财务金额提交请求
    • 验证用户是否可以立即发布请求
    • 验证是否存在用于请求的项目
    • 验证请求的项目是否有效
    • 验证项目是否没有负金额
    • 。。。(进一步验证)
  • 将数据存储到存储库
  • 向用户或相关方发送电子邮件
  • 。。。(可能还有其他步骤需要完成)
上面的例子可能与实际的业务需求相去甚远,但考虑到这一点,我认为这个操作将有大约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)。但就调试代码而言,跟踪它使用的验证类是否会变得更加困难?因为构造函数注入是在实现中定义的,而不是在接口中定义的

考虑最坏的场景,当调试器不是开发人员时,只有一个最小的测试场景,并且根本没有文档

但就调试代码而言,跟踪哪一个会更困难吗 它使用的验证类?因为构造函数注入是在 实现而不是在接口中

是的,这可能会使您在调试时必须跳转到更多的类。然而,这种设计允许对代码进行测试(当然是使用TDD),在练习TDD时,您需要调试的代码比以前少得多

但就调试代码而言,跟踪哪一个会更困难吗 它使用的验证类?因为构造函数注入是在 实现而不是在接口中


是的,这可能会使您在调试时必须跳转到更多的类。然而,这种设计允许对代码进行测试(当然是使用TDD),在练习TDD时,您需要调试的代码比以前少得多。

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

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

就调试而言,我不认为您需要多做一点工作就可以成为不以模块化方式构建代码的理由。只要设置正确的断点就可以了


也许可以给你一些更深入的了解。

你所说的逻辑属于不同的层,但需要注入到你的应用层。我要做的是注入执行任务所需的组件,比如执行请求的命令处理程序;负责验证输入的验证器、处理数据逻辑的存储库和发送邮件的邮件程序组件(或服务)

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

就调试而言,我不认为您需要多做一点工作就可以成为不以模块化方式构建代码的理由。只要设置正确的断点就可以了


也许可以给你更多的见解。

有趣:@Steven是的,我也读过这篇文章。但它讨论的是实体如何在层之间传递,我问的是业务逻辑的分层/分区。不错的文章,但必须读。有趣:@Steven是的,我也读过这篇文章。但它讨论的是实体如何在层之间传递,我问的是业务逻辑的分层/分区。不错的文章,但必须阅读。即使不同的层,它主要包括在服务层。我无法想象更复杂的操作需要更多的服务,或者我可以给它所有的服务层的例子。撇开它不谈,我已经读了一部分(是的,这是一篇很长的文章)的链接,它是好的。然而,我不喜欢其中的两件事。一个是通用存储库接口,也许我只是不知道该用什么,它看起来很复杂。另一个是使用服务定位器(ObjectFactory.GetObject(类型t))。不过这是主观的+顺便说一句,我相信ObjectFactory在属性中只使用一次,因为没有其他方法。其余部分使用构造函数注入。事实上,一旦您拥有了通用存储库,它就不再那么复杂了,因为它可以避免您编写重复的代码。是的,也许我还不太习惯存储库模式,我不知道它的用法。对于对象工厂,为什么不直接注入处理程序呢?还是给工厂注射?静态方法很难测试,无法模拟和创建依赖项。属性中的对象工厂不能被注入,因为它是一个属性,需要一个默认构造函数。所以没有w