通用存储库有真正的优势吗？

正在阅读一些有关为新应用创建通用存储库的优势的文章（示例）。这个主意看起来不错，因为它让我可以使用同一个存储库同时为几种不同的实体类型做几件事：

IRepository repo = new EfRepository(); // Would normally pass through IOC into constructor 
var c1 = new Country() { Name = "United States", CountryCode = "US" };
var c2 = new Country() { Name = "Canada", CountryCode = "CA" };
var c3 = new Country() { Name = "Mexico", CountryCode = "MX" };
var p1 = new Province() { Country = c1, Name = "Alabama", Abbreviation = "AL" };
var p2 = new Province() { Country = c1, Name = "Alaska", Abbreviation = "AK" };
var p3 = new Province() { Country = c2, Name = "Alberta", Abbreviation = "AB" };
repo.Add<Country>(c1);
repo.Add<Country>(c2);
repo.Add<Country>(c3);
repo.Add<Province>(p1);
repo.Add<Province>(p2);
repo.Add<Province>(p3);
repo.Save();

但是，存储库的其余实施都严重依赖Linq：

IQueryable<T> Query();
IList<T> Find(Expression<Func<T,bool>> predicate);
T Get(Expression<Func<T,bool>> predicate);
T First(Expression<Func<T,bool>> predicate);
//... and so on

此存储库模式对Entity Framework效果非常好，并且几乎提供了DbContext / DbSet上可用方法的一对一映射。但是，鉴于LINQ在Entity Framework之外的其他数据访问技术上使用缓慢，与直接使用DbContext相比，这提供了什么优势？

我尝试编写存储库的PetaPoco版本，但PetaPoco不支持Linq表达式，这使得创建通用IRepository接口几乎没有用，除非您仅将其用于基本的GetAll，GetById，Add，Update，Delete和Save。方法并将其用作基类。然后，您必须使用专门的方法创建特定的存储库，以处理我以前可能作为谓词传入的所有“ where”子句。

通用存储库模式对实体框架以外的其他内容有用吗？如果不是，为什么有人要使用它而不直接使用Entity Framework？

原始链接无法反映我在示例代码中使用的模式。这是（更新的链接）。

通用存储库对于Entity Framework 甚至是无用的（恕我直言，也是不好的）。它不会给已经提供的内容带来任何额外的价值IDbSet<T>（这是通用存储库）。

正如您已经发现的那样，可以用其他数据访问技术的实现替换通用存储库的论点非常薄弱，因为它可能要求编写您自己的Linq提供程序。

关于简化的单元测试的第二个普遍论点也是错误的，因为带有内存数据存储的模拟存储库/集将Linq提供程序替换为另一个具有不同功能的提供程序。Linq-to-entities提供程序仅支持Linq功能的子集-它甚至不支持IQueryable<T>界面上可用的所有方法。在数据访问层和业务逻辑层之间共享表达式树可防止伪造数据访问层-必须将查询逻辑分开。

如果您想拥有强大的“泛型”抽象，则还必须涉及其他模式。在这种情况下，您需要使用抽象查询语言，该抽象查询语言可以由存储库转换为使用过的数据访问层支持的特定查询语言。这由规范模式处理。Linq on IQueryable是规范（但翻译需要提供程序-或一些自定义访问者将表达式树转换为查询），但是您可以定义自己的简化版本并使用它。例如，NHibernate使用Criteria API。仍然最简单的方法是使用具有特定方法的特定存储库。这种方法在单元测试中是最简单的实现，最简单的测试和最简单的伪造，因为查询逻辑被完全隐藏在抽象之后并被分开。

问题不是存储库模式。在获取数据和如何获取数据之间进行抽象是一件好事。

这里的问题是实现。假定一个任意表达式可以用于过滤是最好的选择。

直接使所有对象的存储库工作有点错了。数据对象很少会直接映射到业务对象。在这些情况下，将T传递给过滤器变得没有意义。提供这么多的功能几乎可以保证一旦其他提供商出现后，您将无法支持所有功能。

通用数据层（存储库是数据类型的一种特殊类型）的价值在于允许代码更改底层存储机制，而对调用代码几乎没有影响。

从理论上讲，这很好。如您所见，在实践中，抽象通常是泄漏的。一种用于访问数据的机制不同于另一种机制。在某些情况下，您最终要编写两次代码：一次在业务层，然后在数据层重复。

创建通用数据层的最有效方法是事先了解应用程序将使用的不同类型的数据源。如您所见，假设LINQ或SQL是通用的可能会出现问题。尝试改造新的数据存储区可能会导致重写。

[编辑：添加了以下内容。]

它还取决于应用程序对数据层的需求。如果应用程序只是加载或存储对象，则数据层可能非常简单。随着对搜索，排序和过滤器的需求增加，数据层的复杂性增加，抽象开始泄漏（例如，在问题中公开LINQ查询）。但是，一旦用户可以提供自己的查询，则需要仔细权衡数据层的成本/收益。

在几乎所有情况下，在数据库上方都具有代码层是值得的。通常，我更喜欢在上述代码中使用“ GetByXXXXX”模式-它使您可以根据需要优化其背后的查询，同时保持UI不受数据接口混乱的影响。

利用泛型绝对是公平的游戏-拥有一种Load<T>(int id)方法很有意义。但是，围绕LINQ建立存储库相当于在2010年代到处都删除sql查询，并增加了一些类型安全性。

好了，有了提供的链接，我可以看到它可能是的便捷包装器DataServiceContext，但是并没有减少代码操作，也没有提高可读性。此外，访问权限DataServiceQuery<T>受阻，限制了.Where()和的灵活性.Single()。也没有提供AddRange()或替代。也没有Delete(Predicate)提供可能有用的（repo.Delete<Person>( p => p.Name=="Joe" );删除Joe-s）。等等。

结论：这样的API妨碍了本机API并将其限制为一些简单的操作。

我会说“是”。根据您的数据模型，完善的通用存储库可以使数据访问层更精简，更整洁并且更健壮。

阅读本系列文章（@ chris-pratt）：

• 通用实体基类
• 真正通用的存储库，第1部分
• 真正通用的存储库，第2部分