通用存储库设计答案

【问题标题】：Generic Repository design通用存储库设计
【发布时间】：2023-03-08 21:51:01
【问题描述】：

您好，我正在尝试在 EF4 之上创建一个通用存储库。与其采用不同的 Repository 和 UnitOfWork 实现，我希望创建一个存储库类，该类将在其内部维护 ObjectContext 的状态。我的界面如下：

/// <summary>
/// Contract for base generic repository
/// </summary>
public interface IRepository
{
    ActionResult SaveData<TEntity>(TEntity entityObj, bool commitTransaction) where TEntity : IEntity, new();

    ActionResult SaveData<TEntity>(ICollection<TEntity> entityObjects, bool commitTransaction) where TEntity : IEntity, new();

    ActionResult DeleteData<TEntity>(TEntity entityObj, bool commitTransaction) where TEntity : IEntity, new();

    ActionResult DeleteData<TEntity>(ICollection<TEntity> entityObjects, bool commitTransaction) where TEntity : IEntity, new();

    ICollection<TEntity> SelectAll<TEntity>() where TEntity : IEntity, new();
    ICollection<TEntity> SelectByCondition<TEntity>(Func<TEntity, bool> condition) where TEntity : IEntity, new();
}

ActionResult 是告诉我特定事务是否成功执行的类。现在我不想在存储库之外维护事务状态。因此，每次保存/删除时，我们都可以传递 bool 值。第一次，可以在内部检查事务对象，然后当我调用我的最后一个事务时，我可以发送 committransaction true，这将调用 SaveChanges() 函数。

我的问题是：这种方法设计好了吗？我会面临哪些问题？

【问题讨论】：

标签： .net entity-framework-4

【解决方案1】：

我发现这个实现有很多问题。

明确告知每个保存和删除操作是否提交既麻烦又容易出错。只是不小心将一项操作设置为 false 并且您的中断原子性。控制交易不应在该级别进行。
SelectByCondition 采用Func<T, bool> 谓词，这意味着必须在内存中加载和过滤完整的数据库表。更好的设计是使用表达式树。
您说您定义了一个“存储库类，它将在自身内部维护ObjectContext 的状态”，但实际上您定义了一个工作单元:-)，因为存储库用于一种单一类型的对象。
每个方法都采用TEntity 类型参数，而这更适合接口级别，因为这样您将遵循存储库设计模式。示例：IRepository<TEntity>。这样的设计将使使用类型安全。

看看this article。它描述了一种（相当抽象的）实现工作单元和存储库的方法，同时允许您对它们进行 LINQ 查询并允许它们进行单元测试。

【讨论】：

【解决方案2】：

您实际上创建了一个混合工作单元和存储库接口，从而破坏了 SRP。我建议您坚持使用通常通过 IoC 容器注入到您的存储库中的工作单元。您仍然可以使用通用存储库。这是一个已知的模式，有很多社区样本专门围绕 EF（查看我在 Unit Testing EF 上的答案以获取链接）。

在可能的情况下使用通用模式，而不是自己制定模式，将始终更好地为现在或将来的任何开发人员服务于团队。

【讨论】：