实体框架/工作单元架构问题

Question

我非常熟悉 UoW、存储库模式等。但是在看到实体框架模式的各种实现时，我很好奇为什么有人会在其存储库上有 Save 或 Add 方法。如果您使用存储库来获取一个对象的新实例，我想

public Customer GetNewCustomer()
{
    Customer customer = new Customer();
     ... any initialization code here ...
    _context.Customers.AddObject(customer);
   return customer;
}

我在某些设计中已经知道有人会知道该对象，那么您可以简单地使用它

Customer customer = new Customer();

，并且它不会附加到上下文的任何地方。不过，我很喜欢私有构造函数，因此 Customer 对象有一个实例化点。考虑到这一点，在使用 UoW 模式时，在存储库上永远不要有添加/保存方法并且仅在 IUnitOfWork 接口上具有此功能不是有意义吗？

Answer 1

当我遵循 Java 中的 Spring 习惯用法时，工作单元（和事务）与服务相关联。他们使用模型和持久性对象来满足请求。事务使用方面进行标记。

我不知道.NET 是否遵循类似的想法，但值得探索。拥有基于接口的POCO服务并让他们拥有交易。

Answer 2

我不认为你的解决方案是正确的。这会将空客户添加到当前工作单元中。这意味着如果以后的代码决定不通过当前的工作单元来拯救客户，那么它将会遇到困难。

存储库有保存实体的方法是很常见的。您正在组合域驱动设计中使用的两种模式

• 存储库
• 对象工厂

存储库的职责是检索或存储实体。对象工厂的职责是处理实体构建。

顺便提一句。如果存储库不是实体，则实体的私有构造函数将无法在存储库中访问（这将非常糟糕）。

Answer 3

...永远没有添加/保存方法不是有意义吗？
使用 UoW 模式时的存储库并且仅具有此功能
在 IUnitOfWork 接口上？

是的，我认为只在 IUnitOfWork 接口上有 Save 方法是有意义的。但是，我不再将存储库模式与 EF 一起使用。相反，我现在使用 这些 命令的变体查询模式。

如果您仔细想想，EF DbContext 实际上做了 3 件事：1.) 它充当用于读取实体状态的存储库，2.) 作为用于改变实体状态的存储库，以及 3.) 作为用于跟踪多个更改的工作单元并将它们组合成一个事务以持久保存状态突变。

那么，为什么不将这 3 个职责分成 3 个不同的接口呢？

public interface IUnitOfWork
{
    int SaveChanges();
}

public interface ICommandEntities : IQueryEntities
{
    void Create(Entity entity);
    void Update(Entity entity);
    void Purge(Entity entity);
}

public interface IQueryEntities
{
    IQueryable<AggregateRoot1> AggregateRoot1s { get; }
    IQueryable<AggregateRoot2> AggregateRoot2s { get; }
    IQUeryable<AggregateRootN> AggregateRootNs { get; }

    IQueryable<TEntity> EagerLoad<TEntity>(IQueryable<TEntity> query, 
        Expression<Func<TEntity, object>> expression)
        where TEntity : Entity;
}

然后，您可以在 DbContext 类上实现这 3 个接口。这使接口保持良好和隔离，并允许您仅依赖注入您需要的 DbContext 的那些方法。

例如，您的域应该是持久性无知的，对吧？在这种情况下，不要给任何域类依赖 IUnitOfWork 接口。相反，请在 IoC 组合根（或 MVC 操作过滤器）中处理 IUnitOfWork。然后，您的查询和命令处理程序仅处理 ICommandEntities 和 IQueryEntities 接口。