.net – 具有实体框架的存储库模式

存储库一直依赖于数据访问技术。这就是为什么人们正在使用存储库 – 将数据访问依赖性包装到单独的层。如果您决定更改数据访问技术(imho，那就像1％的机会)，您将不得不创建新的存储库，实现与以前相同的接口。

介绍资源库会增加一层新的复杂性。存储库有其优点和缺点。介绍他们只是因为“你以后可以改变数据访问方式”是一个坏的原因。不要因为可能发生的事情而设计您的应用程序。根据当前的实际要求(敏捷方式)设计应用程序，如果需要进行更改则重构代码，这是市场竞争的唯一途径。特性是销售您的SW不是其开放架构进行任何类型的更改(好的，有例外，但在这种情况下，开放架构是顶级要求)。

使用EF时，您可以选择如何创建实体：

>使用cutom工具生成实体对象。这是为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的代码更好的可测试。