c# - 存储库模式是否只能与实体框架一起使用？

Question

我已经使用Entity Framework了repository pattern一段时间了。

前几天我被要求在不使用实体框架的情况下编写数据层，只是简单的旧ADO.NET. 我想知道什么是最好的方法？我是否还使用普通的旧 ADO.NET 为我的 CRUD 操作使用存储库模式？

如果我去Codeplex搜索存储库模式，那么 99.9% 的示例项目都使用实体框架。如果我将普通 ADO.NET 与存储过程一起使用，是否需要使用不同的模式？

Answer 1

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

来自 MSDN

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

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

其他福利：

• 易于在存储库中添加逻辑，例如通过 Web 请求缓存结果
• 可以添加常见查询，例如userRepository.FindByEmailAddress(emailAddress);
• 可以将存储库更改为另一个存储库，例如以最小的努力将 dabase 切换到 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), Remove(entity).

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

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