c# - 存储库是否应该在 Entity Framework 1.0 中使用相同的上下文实例

Question

我已经开始研究我正在做的项目的 Entity Framework ，并沿着存储库模式使用 BLL 的道路前进。据我了解，我应该为每个实体创建一个存储库，这样我就有了

public class UserRepository : IRepository<User>
{ ... }

和

public class AccountRepository : IRepository<Account>
{ ... }

在我看到的示例中，通常的做法是在 using 语句中创建实体上下文并在其中执行获取、更新和保存等操作。

using(var ctx = new AppEntities()
{
    //do whatever
    ctx.SaveChanges();
}

对于对存储库的简单访问，这没问题，但是如果我想通过 BLL 构建 2 个(或更多)存储库之间的交互...

public void SaveSomethingMoreComplex()
{
    //BLL here stuff like validation etc

    _userRepository.GetSomeData();
    _accountRepository.SaveSomeData(account);
    _userRepository.SaveSomeMore(user);

    // Probably should have one final save that affects both repositories???
    // Should be in a transaction scope also?
}

最好为两个存储库使用相同的 AppEntities 实例吗？

同样在这个例子中，最终保存可能应该在 block 的末尾，而不是像我的例子中那样有 2 个和交易的一部分？

如果我确实使用相同的实例，那么将它注入(inject)存储库的构造函数并让它在应用程序的整个生命周期内都存在是否安全，或者是否有某种原因我看到的示例倾向于在一个单一方法调用？

感谢您提供的任何帮助。

Answer 1

在处理存储库模式时，这实际上并不是一个不寻常的问题，它归结为提供一种方法来显式管理工作单元的生命周期(在 Entity Framework 的情况下，就是你的上下文) .

您没有具体说明您是在进行 Web 开发还是 Windows 开发，但在 Web 开发的上下文中，将工作单元的生命周期设置为单个请求并不少见。因此，当您的请求开始时，您会创建您的上下文，然后当它结束时您可以调用 SaveChanges(或 Entity Framework 的任何名称)，这会将更改应用到您之前创建的所有实体在请求过程中搞乱。

在 Windows/服务上下文中，您可能希望为您的单元或工作设置某种明确的生命周期管理，这样您就可以根据您正在做的事情定义 UoW 的范围。我倾向于喜欢包装 UoW 操作的对话隐喻，这意味着我可以使用这样的东西:

using(Conversation.Start())
{
    // mess with the entities
} // Dispose on the object returned from Start will 
  // Save Changes and close the session

当然，这掩盖了其中的一些异常管理内容，您可能希望拥有这些内容，以便在发生故障时回滚更改。

就实现而言，它有点取决于您的基础架构。我通常使用 IoC 容器，因此我将调用 Conversation.Start() 为我创建我的工作单元，并设置 IoC 以返回该特定实例，因此当我创建我的存储库他们得到了当前的 UoW。您还可以在 Conversation 上创建一些工厂方法，以便您可以从对话中获取 Repository 实例。有点取决于您希望可用的 API。

希望这对您有所帮助。