具有实体框架的存储库模式 [英] Repository pattern with Entity framework
问题描述
存储库模式用于从使用的特定数据库和对象关系映射技术（如EF）中抽象出来。因此，如果我决定这样做，我可以轻松地将Linq的实体框架映射替换为SQL。
Repository pattern is used to abstract from particular database and object-relation-mapping technology(like EF) used. So I can easily replace (for example) my Entity framework mappings with Linq to SQL in the future if I decide to do so.
但是当我使用EF时，我有我的来自模型的实体类 - 就是从该视觉图生成的。如果我在我的存储库中使用这个生成的实体类，然后决定用别的替代EF，那么我将删除该视觉实体图，这也意味着也删除类？
But when I use EF I have my entity classes from the model - that is they are generated from that visual diagram. If I use this generated entity classes in my repository and then decide to replace EF by something else then I will delete that visual entity diagram and that means also to delete classes right ?
我正在处理的一点是，我的存储库将依赖于实体框架，即数据访问层，因为它将使用由EF生成的类。
The point I'm addressing is that my repository will be dependent on Entity framework, that is on data access layer because it will use classes generated by EF.
我删除这个依赖关系？
还要注意，我使用EF主要是因为它能够从该可视图生成所有内容 - 我只是设计图表，并让它生成数据库我所有的外键等我非常喜欢，不想再想到SQL命令。
Also note that I use EF primarily because of its ability to generate everything from that visual diagram - I just design the diagram and let it generate database for me with all the foreign keys etc. I like that very much and don't want to even think about SQL commands.
推荐答案
存储库一直依赖于数据访问技术。这就是为什么人们正在使用存储库 - 将数据访问依赖性包装到单独的层。如果您决定更改数据访问技术（imho，那就像1％的机会），您将必须创建新的存储库，实现与以前相同的界面。
A repository is always dependent on data access technology. It is the reason why people are using repositories - to wrap data access dependency to separate layer. If you decide to change data access technology (imho it is like 1% chance that you do it) you will have to create new repositories implementing the same interfaces as former ones.
介绍资源库会增加一个新的复杂层次。存储库有其优点和缺点。介绍他们只是因为你以后可以改变数据访问方式是一个坏的原因。不要因为可能发生的事情而设计您的应用程序。根据当前的实际要求（敏捷方式）设计应用程序，如果需要进行更改则重构代码，这是市场竞争力的唯一途径。特点是销售您的SW不是其开放架构进行任何类型的更改（好的，有例外，但在这种情况下，开放架构是顶级要求）。
Introducing repositoris will add a new layer of complexity. Repositories have their pros and cons. Introducing them just because "you can change data access approach in the future" is a bad reason. Do not design your application because of something can happen. Design the application based on current real requirements (an agile way) and refactor your code if a change is needed - that is the only way how to be competitive in the market. Features are selling your SW not its open architecture for any type of change (ok, there are exceptions but in such cases that open architecture is a top level requirement).
使用EF，您可以选择如何创建实体：
When using EF you have several choices how to create entities:
- 使用cutom工具生成实体对象。这是为EDMX创建代码后面文件的默认方法。它是EFv1（.NET 3.5 SP1）中唯一可用的解决方案。
- 使用T4模板生成实体对象，POCO，STE或任何自定义实体类型（可以修改生成逻辑）。这通常与EFv4一起使用。
- 自己写POCO。这可以与EFv4一起使用，它总是与EF 4.1中的代码第一个方法一起使用。
如果您期望数据访问技术可以未来的变化将使用第二种或第三种方法与POCO。在T4模板的情况下，您可以简单地复制生成的POCO或修改项目文件，以便删除EDMX文件后不会丢失。
If you expect that data access technolgy can change in the future use either the second or the third approach with POCOs. In the case of T4 templates you can simply copy generated POCOs or modify a project file so you will not lose them after deleting EDMX file.
如果您不确定是否第二或第三种方法适合您检查我对这些问题的答案：
If you are not sure if either second or third approach suits you check my answers to these questions:
- ADO.NET DbContext Generator vs. ADO.NET POCO Entity Generator
- EF POCO code only VS EF POCO with Entity Data Model
由于我以某种方式同意@ Patko的答案，您还应该检查 Ayende的博客。他撰写了关于使用存储库和架构应用程序的几篇文章。他正在写关于NHibernate，但可以用EF进行类似的评估。唯一的区别是NHibernate提供了更好的抽象，所以使用直接NHibernate的代码更好的可测试。
Because I somehow agree with @Patko's answer you should also check Ayende's blog. He has written several posts about over using repository and over architecting applications. He is writting about NHibernate but similar decissions can be made with EF. The only difference is that NHibernate offers better abstraction so the code using directly NHibernate is better testable.
这篇关于具有实体框架的存储库模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
