注入依赖关系树是一种模式还是反模式?
例如:
public class ClassExample { private IContainer _container; public ClassExample(IContainer container) { _container = container; } } public interface IContainer { IDependencyA DependencyA { get; set; } IDependencyB DependencyB { get; set; } IDependencyC DependencyC { get; set; } } public interface IDependencyA { } public interface IDependencyB { } public interface IDependencyC { }
当有多个地方需要注入同一组服务时,可能有人使用上述方法来最小化代码重复。代码最终会变成这样: container.DependencyA.DependencyAA.Method(...) 在许多情况下,这使它更冗长,少干。
container.DependencyA.DependencyAA.Method(...)
使用上述方法是好主意还是坏主意(模式/反模式)?或者什么时候是个好主意,什么时候是个坏主意?
我不认为这是一个特别的问题 好的
ClassExample 取决于 IDependencyA IDependencyB & IDependencyC 然后它们都应该作为依赖项被注入。
ClassExample
IDependencyA
IDependencyB
IDependencyC
IDependencyXX 类示例 正如你描述的那样。
IDependencyXX
类示例
*这是一个错误的决定,主要是因为人们迟早会开始注射 IContainer 当他们只需要 独立百科全书 独立数据库 独立百科全书 ). 这是多余的。注入的重点是注入所需的依赖项,而不是“以防万一”地从系统中注入所有可能的依赖项
IContainer
独立百科全书
独立数据库