依赖注入 – Ninject缓存注入的DataContext?生命周期管理?

前端之家收集整理的这篇文章主要介绍了依赖注入 – Ninject缓存注入的DataContext?生命周期管理?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我的存储库中抛出了一系列非常奇怪的错误.未找到或更改行,2个更新中的1个失败…没有任何意义.

就好像我的DataContext实例被缓存了……没有任何意义,我正在考虑职业生涯.

然后我注意到使用Ninject使用依赖注入传递了DataContext实例(这是我第一次使用DI …).我撕掉了依赖注入,一切都恢复了正常.即刻.

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

它是否正确?

编辑:

Ninject绑定如下:

Bind<IPupilBlockService>().To<sqlPupilBlockService>()
   .WithConstructorArgument("db",new dbDataContext());
对于生命周期必须明确管理的任何对象(例如实现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>();

工厂的使用使得非常明确谁是所创建对象的所有者以及谁应该控制其生命周期.这使您的代码更具可读性并遵循principle of least surprise.

UPDATE

自从我提交这个答案以来已有一年多了.我现在经常注入数据上下文而不是使用工厂,并在每个(web)请求的基础上注册它.然而;可能需要改变您需要设计应用程序的方式,因为它总是如此:它取决于.请看一下this answer.

原文链接:https://www.f2er.com/javaschema/282006.html

猜你在找的设计模式相关文章