c# - 使用依赖注入(inject)注入(inject)依赖注入(inject)器

Question

对依赖注入(inject)还很陌生，我想弄清楚这是否是一种反模式。

假设我有 3 个程序集:

Foo.Shared - this has all the interfaces
Foo.Users - references Foo.Shared
Foo.Payment - references Foo.Shared

Foo.Users 需要一个在 Foo.Payment 中构建的对象，而 Foo.Payment 也需要来自 Foo.Users 的东西。这会产生某种循环依赖。

我在 Foo.Shared 中定义了一个接口(interface)，它代理我正在使用的依赖注入(inject)框架(在本例中为 NInject)。

public interface IDependencyResolver
{
    T Get<T>();
}

在容器应用程序中，我实现了这个接口(interface):

public class DependencyResolver:IDependencyResolver
{
    private readonly IKernel _kernel;

    public DependencyResolver(IKernel kernel)
    {
        _kernel = kernel;
    }

    public T Get<T>()
    {
        return _kernel.Get<T>();
    }
}

配置如下所示:

public class MyModule:StandardModule
{
    public override void Load()
    {
        Bind<IDependencyResolver>().To<DependencyResolver>().WithArgument("kernel", Kernel);
        Bind<Foo.Shared.ISomeType>().To<Foo.Payment.SomeType>(); // <- binding to different assembly
        ...
    }
}

这允许我从 Foo.Users 中实例化一个新的 Foo.Payment.SomeType 对象，而不需要直接引用:

public class UserAccounts:IUserAccounts
{
    private ISomeType _someType;
    public UserAccounts(IDependencyResolver dependencyResolver)
    {
        _someType = dependencyResolver.Get<ISomeType>(); // <- this essentially creates a new instance of Foo.Payment.SomeType
    }
}

这使得在这个实例中 UserAccounts 类的确切依赖关系变得不清楚，这让我认为这不是一个好的做法。

还有什么方法可以做到这一点？

有什么想法吗？

Answer 1

虽然有些争议:是的，这是一种反模式。它被称为服务定位器，虽然有些人认为它是一种正确的设计模式，但我认为它是一种反模式。

这个问题是使用例如您的 UserAccounts 类变为隐式而不是显式。虽然构造函数声明它需要一个 IDependencyResolver，但它没有说明应该包含什么。如果您向它传递一个无法解析 ISomeType 的 IDependencyResolver，它就会抛出异常。

更糟糕的是，在以后的迭代中，您可能想从 UserAccounts 中解析一些其他类型。它会编译得很好，但如果/当无法解析类型时，可能会在运行时抛出。

不要走那条路。

根据所提供的信息，不可能准确地告诉您应该如何解决循环依赖的特定问题，但我建议您重新考虑您的设计。在许多情况下，循环引用是抽象泄漏的症状，因此如果您稍微改造一下 API，它可能就会消失 - 需要如此小的更改通常令人惊讶。

一般来说，任何问题的解决方案都是添加另一层间接。如果您确实需要让来自两个库的对象紧密协作，您通常可以引入一个中间代理。

• 在许多情况下，发布/订阅 模式效果很好。
• 如果通信必须双向进行，调解器模式可以提供替代方案。
• 您还可以引入一个抽象工厂来在您需要时检索您需要的实例，而不是要求它立即连接起来。