如何使用数据存储库

Question

我对存储库模式非常陌生，但到目前为止我喜欢如何使用它。我在 codeplex 上找到了这个 implementation。我现在的问题是：

我是否以正确的方式使用存储库模式？

和

谁能为我下面的示例提供更好的解决方案？

这是一个示例（我正在使用 poco），其中我获取了一个在过程早期关闭延迟加载的位置。经过一些 ui 交互后，我想更新位置属性（例如名称）和相关用户（包括添加和删除）：

using (var repo = RepositoryHelper.GetLocationRepository())
using (var repo2 = RepositoryHelper.GetUserRepository(repo.UnitOfWork))
{
    repo.Add(location);
    repo.UnitOfWork.Context.ObjectStateManager.ChangeObjectState(location, EntityState.Modified);

    foreach (var user in location.Users)
    {
        repo2.Add(user);
        if (user.Id != 0)
        {
            repo2.UnitOfWork.Context.ObjectStateManager.ChangeObjectState(user, EntityState.Unchanged);
        }
    }

    foreach (var user in _remove.Where(user => user.Id != 0))
    {
        repo2.Delete(user);
    }

    repo2.UnitOfWork.Commit();
}

该示例正在运行，尽管我对如何使用 Attach 命令感到非常困惑。我认为如果对象来自另一个上下文，则使用它？！但是如果我尝试这样做，我总是会得到一个异常，即该对象正在被另一个上下文使用。可以说，我正在分离位置，之后我无法访问用户集合。

另一个问题（我认为它与此密切相关）：我一直读到，数据库连接应该尽可能短。因此，我将 IDisposable 接口添加到存储库中，因此我可以以与 ObjectContext 相同的方式使用它们。但是我发现了一些示例（我认为也在 wpf 应用程序框架中），这不是通常的方法。那么，我应该遵循什么词呢？

亲切的问候，

马特

Answer 1

关键问题：为什么要使用存储库和工作单元 (UoW) 模式？

人们通常使用这些模式将 EF 代码与内部存储库和 UoW 实现分开。因为上层将完全独立于 EF。

您的实现不提供这种分离。它只是 ObjectContext 和 ObjectSet 的一个奇怪的包装。在这种情况下，您根本不需要存储库和 UoW，您可以直接使用 EF 类。即使使用 EF 类，您仍然可以使您的代码可测试（人们有时会引入存储库和 UoW 的另一个错误原因）。

关于你的第二个问题。 ObjectContext 的生命周期应该尽可能短，但这并不意味着您应该为每个查询创建新的上下文。 ObjectContext 在内部处理连接，仅在需要时打开它。 ObjectContext 应该在短时间内使用的原因是因为它还实现了 UoW 模式以及 IdentityMap 模式（我描述了含义here）。在 WPF 应用程序中，ObjectContext 通常与显示数据以供修改的窗口或控件一样长。