我需要一些建议 构造函数注入方法中的依赖注入.
本文关键字:注入 方法 依赖 构造函数 | 更新日期: 2023-09-27 17:48:54
我对一些架构方法非常感兴趣。我喜欢 DI 和 IOC,但我不了解结构体注入;为什么这么复杂。我在下面编写了使用构造函数注入的代码:
namespace DependencyInjection
{
class Program
{
static void Main(string[] args)
{
ConstructorInjectionClass myCtx = new ConstructorInjectionClass(new PdfFormat());
myCtx.Print();
Console.Read();
}
}
public interface IFormat
{
void Print();
}
public class PdfFormat : IFormat
{
public void Print()
{
Console.WriteLine("Pdf Format Print is completed...");
}
}
// Constructor Injection
public class ConstructorInjectionClass
{
private IFormat _format;
public ConstructorInjectionClass(IFormat format)
{
_format = format;
}
public void Print()
{
_format.Print();
}
}
我在下面写了一些代码。我认为这很简单。
public interface IFormat
{
void Print();
}
public class PdfFormat : IFormat
{
public void Print()
{
Console.WriteLine("Pdf Format Print is completed...");
}
}
public interface ISave
{
void Add();
}
public class Sql: ISave
{
public void Add()
{
Console.WriteLine("Adding to SQL is completed...");
}
}
// Constructor Injection
public class ConstructorInjectionClass
{
public ConstructorInjectionClass(IFormat format)
{
format.Print();
}
public ConstructorInjectionClass(ISave saver)
{
saver.Add();
}
为什么要使用构造函数注入?这两种方法的优缺点?
第一个示例是构造函数注入。 您正在向类注入打印到类中的责任。
在第二个示例中,您将创建一个具有 2 个参数之一的新类,并在构造函数中使用该参数。 这很糟糕,原因如下:
- 你的构造函数
- 不应该真正做大量的工作,这是在构造函数中保存或打印 不同的
- 构造函数正在做不同的事情。 构造函数应仅创建类的新实例。
- 目前尚不清楚不同的构造函数在被赋予不同的对象时是否真的会做一些事情。
- 如果将对象传递给构造函数,然后它只是调用它们,为什么不让构造此类的代码调用
ISave
和IPrint
实现上的方法。 毕竟,它必须具有它们才能将它们传递给方法。 如果你的对象在内部保存这些,那么它们可能是在构造对象时提供的(比如在你的组合根中),并且调用Print
对象的客户端代码不需要知道任何关于ISave
和IPrint
实现存在的事实,
函数注入是关于你的类要求它在构造函数中具有的依赖项,所以很清楚依赖项是什么。 通过要求依赖项而不是创建它们,测试类变得更加简单,因为您可以注入模拟依赖项以进行测试。
第一个选项很好,如果你想添加保存,那么你应该向构造函数添加一个额外的参数,以获得一个ISave
接口以及IPrint
接口,并有一个方法Save
,它将委托给ISave
实现。
通过注入依赖项并编程到接口,可以更轻松地在以后更改功能。 例如,您可以轻松将其发送到文件(通过更改传入的IPrint
接口,或者通过更改传递ISave
实现将其更改为保存到 xml 文件或 Web 服务。 这使您的类与保存和打印实现松散耦合
我会阅读这个优秀的答案,以获取有关 DI/IOC 的更多指导
好吧,与任何模式一样,构造函数注入应该在且仅当使用它是一个好主意时才使用。 你的示例代码有点奇怪...
- 你的第一个例子是正确的。 您的类有一个名为
Print
的方法,该方法依赖于另一个类来执行打印。 它不是实例化此依赖项,而是要求在其构造函数中提供依赖项。 这是依赖反转原则的典型示例。 基本上是:"要求,不要实例化。 - 不过,你的第二个例子不太清楚。 你的班级到底在做什么? 这是干什么用的? 它有两个构造函数,它们对它们的依赖项执行操作,但为什么呢? 类中的其他任何地方都不依赖于这些类型的实例。 那么为什么首先要有包装类呢? 似乎更多...人为的。。。比你的第一个例子。 目前还不清楚代码的架构试图实现什么,因此它不能很好地使用构造函数注入。
假设
您想注入依赖项...您可以通过构造函数注入或通过属性 setter 来执行此操作。 我认为构造函数注入的优势之一是 IOC 使用这种策略。 因此,如果您不确定要使用 IOC,但想进行 DI,那么可能应该使用构造函数注入来过渡到 IOC 后期......容易。。。如果你应该改变主意...