如何处理依赖注入中的构造函数更改

本文关键字：构造函数 注入 依赖 何处理 处理 | 更新日期: 2023-09-27 18:14:47

我在应用程序中使用。net unity依赖注入框架。

这个项目使用了一些"第三方库"(由同一公司的其他团队编写的库)

我以这种方式注册了一些第三方库中的'Car'类:

 unityContainer.RegisterType<ICar,Car>();

现在，开发'Car'类的人认为如果构造函数在构造函数内部接受一个布尔值会更好。

当我得到他们库的新版本时，我的代码在运行时中断(我无法检测构建管道中的错误):

解析构造函数Car的参数'"hasRadio'解决System.Boolean,(没有)' r ' n"、"exceptionType":"Microsoft.Practices.Unity.ResolutionFailedException"…

所以我的问题是，你将如何设法避免这些问题?

引入"永远不要在构造函数中使用原语"这样的规则是最佳实践的问题吗?

是我的测试覆盖率不够好吗?例如，当类构造函数包含一些原语时，我应该检查我的统一依赖图的所有类都是用InjectionConstructor实例化的吗?(我甚至不确定一个人可以做到与UnityContainer，其注册字段不给回InjectionConstructors)

我应该总是从第三方库显式实例化类(与InjectionFactory)，以确保构建管道失败时，其他团队改变构造函数而不改变我的代码?(我不太喜欢这个选项，因为它违反了依赖注入原则:/)

如何处理依赖注入中的构造函数更改

引入"永远不要在构造函数中使用原语"这样的规则是最佳实践的问题吗?

。基本依赖关系可以像其他依赖关系一样使用。许多类需要这样的依赖关系才能工作。例如，与SMTP服务器通信的类需要服务器的地址和端口。

是我的测试覆盖率不够好吗?

你可以添加更多的测试来验证对象图实际上可以被创建，我不确定这有多容易。但是，如果使用纯DI，则可以在编译时检测到此类问题。

我应该总是从第三方库显式实例化类(与InjectionFactory)，以确保构建管道失败时，其他团队改变构造函数而不改变我的代码?

我不认为这里有什么规则。如果你愿意，你可以这么做。但是如果你像我上面提到的那样使用纯DI，你的问题已经解决了。

我不太喜欢这个选项，因为它违反了依赖注入原则

我不认为这违反了依赖倒置原则。然而，我认为你以不同的方式违反了DIP:

如果你正确地应用了依赖倒置原则，那么你就不应该直接从你的应用类中使用ICar抽象，因为它属于第三方组件，而不是你的应用。

您应该在您的应用程序中定义抽象(根据您的应用程序域)，然后创建适配器来实现使用第三方API的此类抽象。例如:

namespace MyApplication
{
    public interface IMyCar
    {
        void DoSomething();
    }
}
namespace Adaptors
{
    public class CarAdaptor : MyApplication.IMyCar
    {
        private readonly ThirdParty.ICar car;
        public CarAdaptor(ThirdParty.ICar car) {this.car = car;}
        public void DoSomething() { car.Do3rdPartyThing();}
    }
}

这里要注意的另一件事是，从类Car的名称来看，这可能是一个可更新的，而不是一个可注入的。你只想注射可注射的药物。

相关文章：