室内设计招标网站,mvc网站入口asp,软件工程介绍,在线制作照片嗨#xff0c;今天#xff0c;我想简单地讨论将依赖项注入您的类的不同方式。 通常#xff0c;您有以下三种注射方法 直接进入字段/属性 通过显式的setter方法 通过显式的构造函数参数 现场注入 这种类型的注入为将所需的依赖项注入到类中提供了某种反射机制。 尽管这… 嗨今天我想简单地讨论将依赖项注入您的类的不同方式。 通常您有以下三种注射方法 直接进入字段/属性 通过显式的setter方法 通过显式的构造函数参数 现场注入 这种类型的注入为将所需的依赖项注入到类中提供了某种反射机制。 尽管这种注入类型的好处是它消除了诸如setter方法或构造函数参数之类的混乱代码但其缺点是这些依赖性是不可见的。 如果从外部查看类则只会看到公共方法并且可能是构造函数。 即使这使您非常清楚地了解了类提供的服务但在我看来它仍然具有以下主要缺点 在为此特定类编写测试时您必须检查该类以查看所需的依赖项并且必须使用DI框架即使是简单的测试也必须使用一种反射机制来注入依赖项模拟/存根/真实。 更糟糕的是传入依赖项的数量隐藏在该类中。 当然您可以使用工具JDepend等pp。告诉您依赖性的数量和方向或者使用一个文件来指定注入但是您必须依靠这种工具或检查类。 我观察到的另一个缺点是与使用Setter或Constructor Injection的情况相比创建具有多个职责的类的机会更高。 就像是 哦让我们使用这个精美的注解在这里注入我们需要的服务...几天/几小时后测试这种野兽是如此的困难 二传手注射 注入器注入工具注入器方法每个依赖项一个DI框架用于注入依赖项。 这是一个变体它使依赖项显式显示并且使您可以清楚地了解特定类的依赖项。 在测试过程中它的好处是您不必使用DI框架或反射机制而可以直接设置依赖项。 这种方法的缺点是您可以构造处于无法使用状态的类。 这是因为如果需要或可选依赖项则无法与外部区分开。 构造函数注入 构造函数注入对类的构造函数进行检测DI框架使用该类来注入依赖项。 这是使依赖关系明确的另一个变体。 与Setter注入相反它可以防止您在不规则状态下创建类。 当然您可以传递null但这不仅仅是一种作弊对吗所以我要说这是最严格的变体 每个依赖项都是强制性的 这种注射类型的好处是 您必须只阅读一种方法即构造函数才能弄清楚此类的依赖关系。 您创建了一个不可变的类它使缓存变得如此简单 同样这里的缺点是您无法区分可选依赖项和必需依赖项。 构造函数强制设置所有字段。 我要讨论的最后一个变体是 混合二传手和构造剂注射 我个人更喜欢此变体混合了Setter和Constructor注入。 这给您 在合同级别上区分强制性依赖项和可选性的能力 清楚说明特定类的依赖项是什么 使您可以轻松地检查班级是否负有重大责任 构建后正确配置的类 与纯方法类似使用这种注入进行测试非常简单。 您不需要DI框架并且可以轻松地将模拟的/存根的/真实的实现传递到要测试的类中。 使用/喜欢什么 这个答案在很大程度上取决于您的框架/团队规则/语言。 但是我强烈建议您使用显式注入变量之一因为它们使您无需使用依赖注入框架即可编写纯单元测试。 翻译自: https://www.javacodegeeks.com/2015/01/dependency-injection-field-vs-constructor-vs-method.html
