EF4 CTP5 的存储库模式

Question

我正在尝试使用 ef4 ctp5 实现存储库模式，我想出了一些东西，但我不是 ef 方面的专家，所以我想知道我所做的是否好。

这是我的数据库上下文

public class Db : DbContext
{
    public DbSet<User> Users { get; set; }
    public DbSet<Role> Roles { get; set; }
}

和存储库：（简化）

public class Repo<T> : IRepo<T> where T : Entity, new()
{
        private readonly DbContext context;

        public Repo()
        {
            context = new Db();
        }

        public IEnumerable<T> GetAll()
        {
            return context.Set<T>().AsEnumerable();
        }

        public long Insert(T o)
        {
            context.Set<T>().Add(o);
            context.SaveChanges();
            return o.Id;
        }
}

Answer 1

您需要退一步思考存储库应该做什么。存储库用于检索记录、添加记录和更新记录。您创建的存储库几乎无法处理第一种情况，处理第二种情况但效率不高，并且根本不处理第三种情况。

大多数通用存储库都有一个类似于“

public interface IRepository<T> where T : class
{
    IQueryable<T> Get();
    void Add(T item);
    void Delete(T item);
    void CommitChanges();
}

要检索记录”的接口，您不能只使用 AsEnumerable() 调用整个集合，因为这会将该表的每个数据库记录加载到内存中。如果您只需要用户名为 username1 的用户，则无需下载数据库的每个用户，因为这将严重影响数据库性能，并且会严重影响客户端性能，但没有任何好处根本不。

相反，正如您从我上面发布的界面中看到的那样，您希望返回一个 IQueryable 对象。 IQuerable 允许调用存储库的任何类使用 Linq 并向数据库查询添加过滤器，并且一旦 IQueryable 运行，它就完全在数据库上运行，只检索您想要的记录。数据库在排序和过滤数据方面比您的系统要好得多，因此最好在数据库上尽可能多地进行操作。

现在，关于插入数据，您的想法是正确的，但您不想立即调用 SaveChanges()。原因是最好在所有数据库操作排队后调用 Savechanges()。例如，如果您想在一个操作中创建一个用户及其个人资料，则不能通过您的方法，因为每个 Insert 调用都会导致数据插入到数据库中。

相反，您想要的是将 Savechanges() 调用分离到我上面的 CommitChanges 方法中。

这也需要处理数据库中的数据更新。为了更改实体的数据，实体框架会跟踪它收到的所有记录并监视它们以查看是否进行了任何更改。但是，您仍然需要告诉实体框架将所有更改的数据发送到数据库。这是通过 context.SaveChanges() 调用发生的。因此，您需要将其作为单独的调用，以便能够实际更新已编辑的数据，而当前的实现无法处理这些数据。

---

Edit:
Your comment made me realize another issue that I see. One downfall is that you are creating a data context inside of the repository, and this isn't good. You really should have all (or most) of your created repositories sharing the same instance of your data context.

实体框架会跟踪在哪个上下文中跟踪实体，并且如果您尝试使用一个上下文中的实体更新另一个上下文中的实体，则会出现异常。当您开始编辑彼此相关的实体时，这种情况可能会发生。这也意味着您的 SaveChanges() 调用不是事务性的，每个实体都是在其自己的事务中更新/添加/删除的，这可能会变得混乱。

我在存储库中对此的解决方案是将 DbContext 传递到构造函数中的存储库中。

Answer 2

我可能会因此被否决，但 DbContext 已经是一个存储库了。当您将域模型公开为具体 DbContext 的集合属性时，EF CTP5 会为您创建一个存储库。它提供了一个类似于集合的接口，用于访问域模型，同时允许您传递查询（作为 linq 或规范对象）以过滤结果。

如果您需要接口，CTP5 不会为您提供接口。我已经将自己的 DBContext 包装起来，并简单地公开了对象中公开可用的成员。它是可测试性和 DI 的适配器。

如果我说的不是很明显，我会发表评论以进行澄清。