依赖注入 – DI：组合根分解

Composition root看起来很奇怪的模式.我们有一个非常大的上帝对象,它知道任何事情.

将组合根分解为某些模块的正确方法是什么,这些模块将封装对象图的自身部分的初始化？

hierarchical dependency injection怎么样？

我不同意组合根是 God Object的前提.虽然从概念上讲,组合根可能包含许多代码行,但它只有一个 single responsibility：组成一个对象图.

组合根可以包含很多数据,并且它本身可以耦合到整个应用程序,但它在概念上只有一种方法.它只有一个改变的理由,那就是你想改变你的应用程序的组成方式.

此外,虽然组合根与应用程序的其余部分耦合,但应用程序代码不知道组合根.因此,根据Dependency Inversion Principle,耦合仅在一个方向上进行.

这样做的一个方法是上帝对象违反了所有五个SOLID principles,而一个组合根至少跟随SRP,ISP和DIP.我认为OCP或LSP不适用于此.

总而言之,如果组合根组成一个大型应用程序,它仍然可以包含很多代码.如果您发现它变得无法管理,那么您应该如何将其分解为更小的代码块？

与分解任何其他代码的方式相同.它取决于它.

我希望我从来没有写过或说组合根只能是一个单一的类.如果我这样做,我想收回那个.在撰写作文集时,我经常将其职责分为多个班级(尽管很少超过一些).您可以应用任何您想要的设计模式或其他OOD技术来实现该目标.然后,Composition Root将在您的实现中成为Facade.

我不能提供更多的指导,因为它取决于应用程序架构.如果进行垂直切片,则很可能需要以不同于水平分层的方式构造组合根,等等.

也就是说,作为一般规则,我认为尝试将依赖图分解为子树并不有用.首先,因为依赖图是一个图,而不是一棵树,还因为你经常需要交错多个独立的问题.例如,您可以拥有负责应用程序各个子部分的子图,但是您需要在整个过程中交错相同的日志记录机制,相同的缓存机制或相同的安全机制等.整个图表.如果你试图将它们分开,你不能轻易做到这一点.