.net - 带有 Entity Framework 的存储库模式

Question

存储库模式用于从使用的特定数据库和对象关系映射技术(如 EF)中抽象出来。因此，如果我决定这样做，将来我可以很容易地用 Linq to SQL 替换(例如)我的 Entity Framework 映射。

但是当我使用 EF 时，我有来自模型的实体类——也就是说，它们是从那个可视化图表生成的。如果我在我的存储库中使用这个生成的实体类，然后决定用其他东西替换 EF，那么我将删除该可视实体图，这也意味着删除类对吗？

我要解决的问题是我的存储库将依赖于 Entity Framework ，即数据访问层，因为它将使用 EF 生成的类。

如何删除此依赖项？

另请注意，我使用 EF 主要是因为它能够从该可 View 表生成所有内容 - 我只是设计图表并让它为我生成包含所有外键等的数据库。我非常喜欢这一点，甚至不想想想 SQL 命令。

Answer 1

存储库始终依赖于数据访问技术。这就是人们使用存储库的原因 - 将数据访问依赖包装到单独的层。如果您决定更改数据访问技术(恕我直言，您这样做的可能性为 1%)，您将不得不创建新的存储库来实现与以前相同的接口(interface)。

引入存储库将增加一层新的复杂性。存储库有其优点和缺点。仅仅因为“您将来可以更改数据访问方法”而引入它们是一个不好的理由。不要因为可能发生某些事情而设计您的应用程序。根据当前的实际需求(一种敏捷方式)设计应用程序，并在需要更改时重构代码——这是在市场上保持竞争力的唯一方法。功能是出售您的 SW，而不是针对任何类型的更改的开放式架构(好吧，有异常(exception)，但在这种情况下，开放式架构是最高级别的要求)。

使用 EF 时，您有多种创建实体的选择:

使用 cutom 工具生成 Entity 对象。这是为 EDMX 创建“代码隐藏”文件的默认方法。它是 EFv1 (.NET 3.5 SP1) 中唯一可用的解决方案。

使用 T4 模板生成实体对象、POCO、STE 或任何自定义实体类型(您可以修改生成逻辑)。这通常与 EFv4 一起使用。

自己写 POCO。这可以与 EFv4 一起使用，并且始终与 EF 4.1 中的代码优先方法一起使用。

如果您预计数据访问技术将来会发生变化，请使用 POCO 的第二种或第三种方法。对于 T4 模板，您可以简单地复制生成的 POCO 或修改项目文件，这样您在删除 EDMX 文件后就不会丢失它们。

如果您不确定第二种或第三种方法是否适合您，请查看我对这些问题的回答:

ADO.NET DbContext Generator vs. ADO.NET POCO Entity Generator

EF POCO code only VS EF POCO with Entity Data Model

因为我以某种方式同意@Patko 的回答，所以您还应该检查 Ayende's blog .他写了几篇关于过度使用存储库和过度构建应用程序的文章。他正在撰写有关 NHibernate 的文章，但可以使用 EF 做出类似的决定。唯一的区别是 NHibernate 提供了更好的抽象，因此直接使用 NHibernate 的代码具有更好的可测试性。