我一直在使用Entity Framework和repository pattern一段时间了。存储库模式仅用于实体框架吗？
我被问到有一天不使用实体框架写的数据层，只是普通的旧ADO.NET。我想知道什么是最好的方法呢？我是否还使用普通的旧ADO.NET对我的CRUD操作使用存储库模式？
如果我转到Codeplex并搜索存储库模式，则所有示例项目中有99.9％使用实体框架。如果我使用普通的ADO.NET和存储过程，是否需要使用不同的模式？
不，存储库模式在实体框架之外被广泛使用，并且是处理数据访问的全面有用的方式。
从MSDN
http://msdn.microsoft.com/en-us/library/ff649690.aspx
其他好处：
userRepository.FindByEmailAddress(emailAddress);Martin Fowler的“企业架构模式”，提供了一种用于存储库中的以下定义：使用用于访问域对象的集合状界面域和数据映射层之间
介导。
的常用方法来实现，在C＃是有一个通用的Repository<T>类，其中T是一个实现IQueryable<T>并提供像Add(entity)，Remove(entity)另外的方法持久对象。
没有ORM就很难实现。您可以创建一个更简单的存储库，将SQL语句作为WHERE条件使用，但可能会变得混乱。
许多示例对具有不同持久性方法的每种类型使用具体的存储库类。但那些只是伪装的DAO类。
我不完全同意你的看法。当他定义模式时，泛型甚至不存在。它们是使用内存中的集合来模拟它的众多例子。 – scartag 2013-04-10 16:39:19
我刚刚提供了实现存储库的常用方法。您绝对可以简化实现以使用SQL语句返回并实现对象。 – 2013-04-10 16:40:28
通用存储库不好，只有一个例外：您的所有存储库看起来都是一样的，并且在同一个地方持续存在（例如，以序列化形式将所有内容存储在一个表中的域存储库）。存储库公开的Iqueryable是一种反模式，原因有两个：1）它假定业务对象与底层数据存储实体相同，大多数情况下ORM实体和Iqueryable指定如何构建查询回购的关注。你不告诉存储库如何做东西，你告诉它你想要什么。 – MikeSW 2013-04-11 05:49:59
我不认为这是正确的方法。但有一些假设
在EF代码上添加一个存储库模式。这使您远离ORM的功能。实体框架已经是数据库的抽象层。
如果您想使用EF上的依赖注入和测试驱动开发，那么您需要遵循Repository Pattern。通过使用RP，您的代码变得可测试和可注入/可维护。
开箱即用的EF并不是非常容易测试的，但通过可以注入的接口制作EF数据上下文的可模拟版本非常容易。
如果我们不希望我们的代码是可测试或可注射的，那么就不要使用RP。
我看到一篇博文：http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern
但你有没有看到这篇文章？ http://www.sapiensworks.com/blog/post/2012/10/10/Do-We-Need-The-Repository-Pattern.aspx;） – MikeSW 2013-04-13 19:14:00
我没有看过这篇文章。也许我应该写一篇名为“我应该何时使用ORM存储库模式”的新的nogginbox博客文章。很多很好的理由在Sapiens工作的文章中，为什么你会。如果你只是想包装你的ORM来使其可测试，那么不需要。如果您有多个要隐藏的数据源，或者计划稍后换出数据层，那么也许是。 – 2017-12-13 10:20:32
不，绝对不是。存储库模式是数据访问的通用模式 - 无论您访问数据的方式如何，都可以在访问数据时使用。 – 2013-04-10 16:34:01
实际上，使用存储库模式的整个*点*是将您的应用程序与访问数据的方式隔离开来。 EF常常是对该框架有多么有用的证明，或者是在dotnetland中缺乏替代品。 – millimoose 2013-04-10 16:36:43