c# - 在类库中初始化 IoC 容器的好策略是什么？

Question

我正在编写一个类库(用 C# 编写)，它将与我无法控制的应用程序一起分发。我的库也有点安全敏感，因此我不想允许调用应用程序对类库的依赖项进行任何配置。它必须是独立的并初始化自己的依赖项。

同时，我希望它是可单元测试的且松散耦合的，并且我想使用 IoC 容器来管理依赖项。目前我正在使用内部构造函数和 [InternalsVisibleTo()] 以便单元测试可以进行手动注入(inject)。我更喜欢使用 Ninject 作为我的 IoC 容器，但我认为这与问题无关。

我正在努力想出一个好的策略来在生产中初始化我的 IoC 容器，因为类库实际上没有定义的入口点，它有许多类可以实例化，但无法知道应用程序将首先使用哪一个。

我想知道是否可能有某种 AssemblyLoad 事件，事实上 AppDomain 似乎有这样的事件，但我的程序集必须已经加载到在我可以连接到 AppDomain 之前，所以我总是会错过加载我自己的程序集引发的事件。我还考虑过使用静态初始化程序或构造函数，但我不太乐意用 IoC 容器设置污染每个可能的类，因为这会使它们与容器紧密耦合。我不想解耦我的代码，然后将其耦合到 IoC 容器。

我发现了一些讨论该主题的其他问题，但没有一个真正涉及我的情况。一位建议使用静态初始化程序，另一位建议应用程序应始终是组合根。

还有别的办法吗？

Answer 1

您的要求之间存在矛盾。

首先，出于安全考虑，您不需要组合根。其次，您希望由容器来解决依赖关系。但由于库不控制容器，几乎任何东西都可以注入(inject)到你的代码中，包括试图从内部破坏任何东西的东西。

一种方法是明确您的依赖项，以便库客户端负责提供您的依赖项。

namespace Library
{
    public class Foo1
    {
        //  a classical IoC dependendency
        public Foo1( IBar bar )
        {
        }
    }
}

另一方面，使用组合根(Composition Root)作为初始化库的显式外部点仍然并不意味着您的库受到污染。 CR 与本地工厂(又名依赖解析器)配合得很好，本地工厂负责内部对象创建，并且是从 CR 内部设置的。

namespace Library
{
    public interface IFoo { }

    // local Foo factory, with a customizable provider
    public class FooFactory
    {
        private static Func<IFoo> _provider;
        public static void SetProvider( Func<IFoo> provider )
        {
           _provider = provider;
        }

        public IFoo CreateFoo()
        {
            return _provider();
        }
    } 

    // Bar needs Foo
    public class Bar
    {
        public void Something()
        {
            // you can use the factory here safely
            // but the actual provider is configured elsewhere
            FooFactory factory = new FooFactory();

            IFoo foo = factory.CreateFoo();
        }
    }
}

然后是组合根目录中的某个位置(靠近应用程序的入口点)

// kernel is set up to map IFoo to an implementation of your choice
public void ComposeRoot( IKernel kernel )
{
    FooFactory.SetProvider( () => kernel.Get<IFoo>() );
}

正如您所看到的，本地工厂不是在多个类中提供多个注入(inject)点，而是一个单一的注入(inject)点，它提供了整个库的干净配置，使其成为独立的。

您甚至可以拥有一个不涉及任何 IoC 容器的提供程序，而是创建一个具体的实现，从而使其无需任何容器即可轻松测试。切换到另一个 IoC 很简单，您只需提供另一个提供程序即可。

您的库越大并且您的类具有凝聚力(经常互相使用)，拥有本地工厂就越方便。您不需要重新抛出类之间的依赖关系(如果您的类A需要I和您的B，则无需本地工厂 需要 A，然后自动 B 需要 I)，相反，所有类都依赖于一个工厂。