存储库模式是否仅用于实体框架？

Question

我一直在使用Entity Framework和repository pattern。

前几天我被问到不使用Entity Framework编写数据层，只是简单的ADO.NET。我想知道最好的办法是什么？我是否还使用普通的旧ADO.NET对我的CRUD操作使用存储库模式？

如果我转到Codeplex并搜索存储库模式，那么99.9％的所有示例项目都使用Entity Framework。如果我使用普通的ADO.NET和存储过程，是否需要使用不同的模式？

Answer 1

不，存储库模式在实体框架之外广泛使用，并且是处理数据访问的全面有用方式。

来自MSDN

• 它集中了数据逻辑或Web服务访问逻辑。
• 它为单元测试提供了替换点。
• 它提供了一个灵活的架构，可以根据应用程序的整体设计进行调整。

http://msdn.microsoft.com/en-us/library/ff649690.aspx

其他好处：

• 在存储库中添加逻辑非常简单，例如通过Web请求缓存结果
• 可以添加常见查询，例如userRepository.FindByEmailAddress(emailAddress);
• 可以使用其他存储库更改存储库，例如以最小的努力将数据库转换为Web服务

Answer 2

我认为这不是正确的方法。但是有一些假设

在EF代码之上添加存储库模式。这样可以使您远离ORM的功能。实体框架已经是数据库的抽象层。

如果要使用依赖注入和测试驱动开发而不是EF，那么请遵循存储库模式。通过使用RP，您的代码变得可测试且可注入/可维护。

开箱即用的EF不是很容易测试，但是很容易用可以注入的接口制作一个可模拟的EF数据上下文版本。

如果我们不希望我们的代码可测试或可注射，那么就不要使用RP。

我看了一篇博文：http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern

Answer 3

Martin Fowler的“企业架构模式”，为存储库提供了以下定义：

  

使用类似集合的接口访问域对象，在域和数据映射层之间进行调解。

在C＃中实现它的一种常见方法是拥有一个通用Repository<T>类，其中T是实现IQueryable<T>的持久对象，并提供其他方法，如Add(entity)，{{1} }。

没有ORM就很难实施。您可以创建一个更简单的存储库，将SQL语句作为WHERE条件，但它可能会变得混乱。

许多示例使用具有不同持久性方法的每种类型的具体存储库类。但那些只是伪装成DAO类。