在DbContext实例上有一个俘虏依赖项是否不好?

也许这个问题有一些解释,但找不到最好的解决办法:

blog post 从Mark Seemann关于俘虏依赖性的文章中,据我在文章末尾的理解,他得出结论:永远不要使用或至少尝试避免俘虏依赖性,否则会有麻烦( 到目前为止还可以 ). 这是另一个 post

他们建议仅通过以下方式使用捕获依赖项: 目的 当你知道你在做什么的时候! ). 这让我想到了我网站上的一个情况。我有10种服务,它们都依赖于 DbContext 用于数据库操作。我认为他们可以很容易地注册为 InstancePerLifetimeScope 如果我为你解决这个问题 DbContext 我不会把它永远留在我的记忆中(在我的案例中,我正在使用Autofac)。所以,我认为一个很好的起点应该是按照生命周期实例和 DbContext

public class MyService
{
    private readonly IDbContext _dbContext = DependencyResolver.Current.GetService<IDbContext>();

    private MyModel GetMyModel() => Mapper.Map<MyModel>(_dbContext.MyTable.FirstOrDefault());
}

在我的创业课程中,我有:

builder.RegisterType<ApplicationDbContext>().As<IDbContext>().InstancePerRequest();
builder.RegisterType<MyService>().As<IMyService>().InstancePerLifetimeScope();

这个模式正确吗?我的意思是不保持 dbContext 从本服务的任何问题到本服务的任何执行,如果该问题是永久性的:

 private readonly IDbContext _dbContext = DependencyResolver.Current.GetService<IDbContext>();

与构造函数注入相比(从dbContext到数据库有很多调用,所以我担心 IDbContext

我想要的理由 每个请求都是实例,而不是每个依赖项都是实例,这就是我在 dbContext

控制器中的常规方法如下所示:

public ActionResult DoSth()
{
     using(var unitOfWork = UnitOfWorkManager.NewUnitOfWork())
     { 
          //do stuff
          try
          {
              unitOfWork.Commit();
              return View();
          }
          catch(Exception e)
          {
              unitOfWork.RollBack();
              LoggerService.Log(e);
              return View();
          }
     }
}

除了DbContext ),是否存在在服务内部的每个方法上应用async Wait以使其成为非阻塞方法的问题。我问这个问题,使用async Wait for dbContext 举个例子,举个例子,我会说:

public async MyModel GetMyModel()
{
   var result = //await on a new task which will use dbcontext instance here
   return Mapper.Map<MyModel>(result);
}

非常感谢您的任何建议!