Ninject 缓存注入的 DataContext？生命周期管理？

Question

我的存储库中出现了一系列非常奇怪的错误。未找到或更改行，2 次更新中有 1 次失败...没有任何意义。

就好像我的 DataContext 实例被缓存了......没有任何意义，我正在考虑职业变动。

然后我注意到 DataContext 实例是使用依赖注入、使用 Ninject 传入的（这是我第一次使用 DI...）。我删除了依赖注入，一切都恢复正常。即刻。

所以依赖注入是问题所在，但我仍然不知道为什么。我推测 Ninject 正在缓存注入的 DataContext。

这是正确的吗？

编辑：

Ninject 绑定如下：

Bind<IPupilBlockService>().To<SqlPupilBlockService>()
   .WithConstructorArgument("db", new dbDataContext());

Answer 1

对于任何生命周期必须显式管理的对象（例如实现 IDisposable 的对象）或对用户很重要的对象，请尝试不要注入它们，而是注入一个允许创建此类对象的工厂。例如定义这个接口：

public interface IDbDataContextFactory
{
    dbDataContext CreateNew();
}

并按如下方式使用它：

public class SqlPupilBlockService
{
    private IDbDataContextFactory contextFactory;

    public SqlPupilBlockService(
        IDbDataContextFactory contextFactory)
    {
        this.contextFactory = contextFactory;
    }

    public void DoSomeOperation()
    {
        using (var db = this.contextFactory.CreateNew())
        {
           // use the dbDataContext here.
        }
    }
}

的实现将非常简单，如下所示：

public class DbDataContextFactory : IDbDataContextFactory
{
    public dbDataContext CreateNew()
    {
        return new dbDataContext();
    }
}

注册过程如下：

Bind<IDbDataContextFactory>().To<DbDataContextFactory>();

工厂的使用使得非常明确谁是所创建对象的所有者以及谁应该控制它的寿命。这使您的代码更具可读性，并遵循最小惊喜原则。

更新

自从我提交这个答案以来已经过去一年多了。我现在经常注入数据上下文本身，并根据每个（网络）请求进行注册，而不是使用工厂。然而;与往常一样，您可能需要改变应用程序的设计方式：这取决于情况。请查看此答案。

Answer 2

@Steven 给出了很好的解释，但实际上，Ninject 已经为您提供了一种指定为每个请求生成实例的方法： InRequestScope。

Bind<IPupilBlockService>()
   .To<SqlPupilBlockService>()
   .InRequestScope()
   .WithConstructorArgument("db", new dbDataContext());

Answer 3

查看激活行为。您的 DataContext 可能被绑定在 Singleton 作用域中，或者其他作用域之一，这将导致从内核返回相同的实例，具体取决于您的调用上下文。

（我对 ninject 不太熟悉，但给定瞬态范围是默认值，我希望在您的应用程序代码中的某个位置 DataContext 被明确定义为具有非瞬态范围）