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

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

但是当我使用EF我有我的实体类从模型 – 这是从该视觉图生成。如果我在我的存储库中使用这个生成的实体类，然后决定用其他东西替换EF，那么我将删除该视觉实体图，这也意味着也删除类吗？

我正在处理的一点是，我的存储库将依赖于实体框架，即数据访问层，因为它将使用由EF生成的类。

如何删除这种依赖关系？

还要注意，我使用EF主要是因为它能够从该可视图生成所有东西 – 我只是设计图表，让它为所有的外键生成数据库等。我非常喜欢，不想甚至考虑SQL命令。

解决方法

介绍资源库会增加一层新的复杂性。存储库有其优点和缺点。介绍他们只是因为“你以后可以改变数据访问方式”是一个坏的原因。不要因为可能发生的事情而设计您的应用程序。根据当前的实际要求(敏捷方式)设计应用程序，如果需要进行更改则重构代码，这是市场竞争的唯一途径。特性是销售您的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的代码更好的可测试。

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!