entity-framework - 每次使用都需要创建/处理的项目的依赖注入(inject)

Question

对于每次使用时都需要创建/处置的依赖项，处理 DI 的正确方法是什么？也就是说:只应在 using 语句的上下文中使用的依赖项...

public void Foo()
{
    IUnityContainer myContainer = GetContainer();
    using (IDataStore store = myContainer.Resolve<IDataStore>())
    {
        //Do work...
    }
} 

我的具体问题

我的应用程序的 DbContext实现一个 IDataStore界面。因为 DbContext 不是线程安全的，而我的业务类需要，所以我的业务类需要创建一个新的 IDataStore。任何时候他们需要与数据库交互的实例。

我尝试了 3 种不同的方法，但它们都有问题:

1. 使用每个业务对象都可以访问的静态 IUnityContainer(如单例)，并解析 IDataStore 的新实例需要的时候。作为额外的好处，此 IUnityContainer 可用于通常无法使用 DI 的静态方法。
2. 依赖项将我的 IUnityContainer 注入(inject)每个业务类，并解析一个新实例 IDataStore需要的时候。
3. 依赖项将我的 IDataStore 注入(inject)每个业务类。

使用方法 1，一切正常。但这显然是一种反模式。有很多显式.Resolve<IDataStore>()业务代码中发生的调用。这也意味着每个业务对象都使用相同的 IUnityContainer，尽管现在这似乎不是问题。

使用方法 2 我的所有业务类在创建其他业务类的实例时都需要传递相同的 IUnityContainer。 DI 你的 IoC 容器显然也被认为是一种不好的做法。

使用方法 3，我无法从类中创建新的 IDataStore 实例。如果我使用 using block ，这意味着我只能使用 IDataStore 一次(因为它将被处置)。如果我不使用 using block ，IDataStore 实例将很可能在一个线程上创建，然后在另一个线程上使用(导致 DbContext 的线程问题)。不仅如此，现在我的每个业务类都需要在其构造函数中向它们传递 IDataStore(或具有属性集)。这使得线程问题更有可能发生，因为许多业务类实例化其他业务对象并且必须使用它们自己的 IDataStore 来执行此操作。

对我来说，似乎方法 1 是这三种方法中最好的，它允许我在每次解析它时创建一个新的 IDataStore 实例。但如果这是一种不好的做法，我想知道为什么。有没有更好的方法来做到这一点？

更新

我现在在想，我可能需要一个依赖注入(inject)的 IDataStoreFactory 接口(interface)，而不是 IDataStore 本身。这意味着具体的工厂类必须实例化 IDataStore 的特定实现...

public Interface IDataStoreFactory
{
    IDataStore CreateNew();
}

public class MyDbContextFactory: IDataStoreFactory
{
    public IDataStore CreateNew()
    {
        return new MyDbContext();
    }
}

然后在我的其他类(class)...

public class SomeClass
{
    private IDataStoreFactory factory;

    public SomeClass(IDataStoreFactory factory)
    {
       this.factory = factory;
    }

    public void Foo()
    {
        using (IDataStore store = factory.CreateNew())
        {
           //Do work...
        }
    }
}

这是解决此问题的有效方法，还是一种不好的做法？我以前没有真正使用过 DI(或工厂)，所以我想确保我没有在做一些会阻碍我前进的事情。

Answer 1

依赖注入(inject)本质上是一组与 Dependency Inversion Principle 相关的模式。 .正如 Robert C. Martin 在 APPP, chapter 11 中解释的那样:“客户[...]拥有抽象接口(interface)”。这意味着接口(interface)是由客户端需要定义的，而不是由任何特定实现提供的。

具体来说，这意味着接口(interface)不应该从 IDisposable 派生，因为客户端永远不需要他们的依赖项是一次性的；这种担忧完全与具体实现有关。

这里的重点是 IDataStore 不应派生自 IDisposable。相反，它应该只公开客户端需要 的方法。让我们调用这样的方法 Bar。

任何客户端都应该能够使用IDataStore的任何实现:

var baz = this.store.Bar(qux);

其中 this.store 是 IDataStore 的实例。

那么你如何处理需要处理的对象呢？

您使用 Decoraptor .具体来说，您创建一个 IDataStore 的实现，负责数据库上下文的生命周期管理:

public class DataStoraptor : IDataStore
{
    public IBaz Bar(IQuz qux)
    {
        using (var ctx = MyDbContext())
        {
            return ctx.Bar(qux);
        }
    }
}

这个简化的示例假设 IDataStore 只定义了一个名为 Bar 的成员，但我相信您可以从示例中推断出来。

此示例的缺点是它会为每个方法调用创建一个新的 MyDbContext。这是安全的，但可能不是最有效地利用资源。例如，如果您有多个客户端在同一线程中使用 IDataStore，您可能希望能够在该线程中重复使用 MyDbContext 的单个实例。在这种情况下，您可以使用 a variation of Decoraptor that takes an Abstract Factory as a dependency .然后，您可以通过返回特定线程(或其他类型范围)范围内的实例的方式来实现该抽象工厂。

不过，这种变化要复杂得多，所以在增加这种复杂性之前，请确保您需要它。 衡量性能，只要性能足够好，就坚持上面显示的更简单的实现。