抽象类和依赖注入

-2 c# abstract-class dependency-injection

我想了解如何实现依赖注入,但我有一些问题:

  1. 我可以使用抽象类吗?我读了一些关于 DI 的文章,如果我理解得很好,他们说你必须使用接口而不是抽象类 - 如何避免在不同的类中使用重复的代码?

  2. 如果我在一个类中有很多依赖项,我是否必须将它们全部注入到构造函数中?如果我不在所有方法中使用所有这些怎么办?

  3. 我可以实例化对象吗?如果我不实例化对象,我如何调用类的构造函数?

srk*_*srk 5

我可以使用抽象类吗?

是的。然而,在实践中,使用接口可能有一些优点。例如,在测试时,有时模拟接口比抽象类更容易。我还想问为什么你觉得需要使用抽象类而不是接口,但这导致了下一点......

如何避免在不同的类中使用重复的代码?

一般来说,为了代码重用,您应该更喜欢组合而不是继承

如果我在一个类中有很多依赖项,我是否必须将它们全部注入到构造函数中?

不,还有其他方法可以注入依赖项,例如方法。但我想说构造函数注入是“经典”DI 模式,并且它有一些优点。例如,如果您在构造函数中注入所有依赖项,那么您无需担心有人在设置所需的依赖项之前调用您的类上的方法。

如果我不在所有方法中使用所有这些怎么办?

小规模来说这是可以的。但是,如果您有很多依赖项或很多方法,这可能表明您的类做得太多了。如果您有不同的方法/依赖项组(例如,如果方法 A、B、C 使用依赖项 1、2,方法 D、E、F 使用依赖项 3、4),则尤其如此。请参阅 单一职责原则

我可以实例化对象吗?如果我不实例化对象,我如何调用类的构造函数?

考虑不同类型的课程很重要。对于仅保存数据的简单 POCO 类,您不需要使用 DI - 请根据new需要随意添加它们。然而,DI 对于执行某些业务逻辑或与数据库等外部系统交互的服务类型类非常重要。在这种情况下,您new应该在类中实例化它们。

当然,您必须在某个时候实例化这些对象。但 DI 的要点是,依赖于 X 的类不应该实例化 X。依赖注入框架通常有一个“组合根”,所有依赖项都连接在其中。您将在此处看到正在创建的新实例。