0

我在尝试设置 DI 时遇到了一个小障碍。

所以鉴于我有这个控制器：

public UsersController(IUnitOfWork unitOfWork)
{
   // Stuff
}

我以前有这个直接访问我的存储库的 UnitOfWork 实现。

public class UnitOfWork : IUnitOfWork, IDisposable
{
  private readonly DbContext _context = new DbContext();

  public IRepository<User> Users { get { return new UserRepository(_context); } }
}

Ninject UnitOfWork 代码：Bind<IUnitOfWork>().To<UnitOfWork>().InRequestScope();

现在这实际上工作正常。但是我想改变它，而不是包含存储库的 UnitOfWork，它包含接受多个存储库的服务。

public class UserService : IUserService
{
  private readonly IUserRepository _userRepository;
  public UserService(IUserRepository userRepository, /* Other repositories */)
  {
    _userRepository = userRepository;
  }
}

现在我能想出的唯一解决方案是

public class UnitOfWork : IUnitOfWork, IDisposable
{
  private readonly DbContext _context = new DbContext();

  public IUserService UserService
  {
    get
    {
      return new UserService(new UserRepository(_context), /* etc. */);
    }
  }
}

这似乎不对。现在我正在自己创建所有服务依赖项。

我在 StackOverflow 上看到过帖子提到最好让服务访问多个存储库并处理业务逻辑，而不是让控制器（MVC 应用程序）担心它。

但是，找不到有关如何正确执行此操作的任何细节。那么我怎么能使用 Ninject 来做我所追求的呢？

4

1 回答 1

2

抱歉，这确实是一个杂草丛生的评论，但是嘿...

ADbContext 是一个工作单元，创建一个跨越两个 DbContexts 的怪物工作单元绝对不是一般模式（因此你的问题是你的问题）

此处对相关问题的此答案的评论偏离了同一领域。

在尝试以这种方式解决之前要问自己的问题：

  • 除了拥有 DbContext 之外，您还试图用我的这个工作单元来完成什么？
  • 这需要交易吗？
  • 中间是否真的有一个缺失的服务应该有自己的数据来引用另外两个？
  • 这是否需要跨越两个有界上下文？如果您以后需要再次将它们拉出怎么办？
  • 如果我的应用中有 3 个这样的案例，我会继续将它们合并到一个 BC 中吗？4？

对我来说，关键是创建自己的 UoW 来包装 UoW：

  1. 不会给你买太多
  2. 让你更难推理你的核心问题

如果你仍然打算用 Ninject 硬塞这些东西，技术方法是一起使用上下文保留和工厂扩展 - 去阅读他们 wiki 中的示例。如果您决定将其剥离，它们可能还有部分可玩。

更新：我现在明白你的意思了——重要的是链接到那些引导你提前思考的东西。首先，去阅读这个。接下来，决定您是否要拥有一个工作单元。如果是这样，谁以及在哪里将提交和处置它？

如果存储库和/或服务将共享 UoW 或 DBContext 并且某些内容将集中提交内容，那么您将要共享/处置的内容绑定到 InRequestScope 以拥有它 a) 获取单个共享实例 b) 获取处理

我主要关心的是所有这些抽象是否真的都有益于事物——你是否真的在编写使用抽象的测试（而不仅仅是前几个）？你真的要切换存储库吗？我个人会去读几次 DDD 书，作为更好的时间投资。

我意识到其中很多都是高度光顾的，这只是一个代表更大问题的一部分的简化问题，但我刚刚看到最近包装层和 DI 容器诡计的交叉点引发的太多问题，因此我的咆哮。吐槽完毕，谢谢！

于 2013-04-05T21:18:53.697 回答