具有实体框架的存储库模式
存储库模式用于从所使用的特定数据库和对象关系映射技术（如 EF）中进行抽象。因此，如果我决定这样做，将来我可以轻松地用 Linq to SQL 替换（例如）我的实体框架映射。
但是当我使用 EF 时，我从模型中获得了实体类 - 即它们是从可视化图表生成的。如果我在我的存储库中使用这个生成的实体类，然后决定用其他东西替换 EF，那么我将删除该可视实体图，这也意味着删除类，对吧？
我要解决的问题是，我的存储库将依赖于实体框架，即数据访问层，因为它将使用 EF 生成的类。
如何消除这种依赖性？
另请注意，我使用 EF 主要是因为它能够从可视化图表生成所有内容 - 我只是设计图表并让它为我生成包含所有外键等的数据库。我非常喜欢这一点，甚至不想考虑一下 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.
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 ?
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.
How do I remove this dependency ?
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
存储库始终依赖于数据访问技术。这就是人们使用存储库的原因 - 将数据访问依赖项包装到单独的层。如果您决定更改数据访问技术（恕我直言，您这样做的可能性大约为 1%），您将必须创建新的存储库，实现与以前的存储库相同的接口。
引入存储库将增加新的复杂性。存储库有其优点和缺点。仅仅因为“您将来可以更改数据访问方法”而引入它们是一个糟糕的理由。不要因为可能发生某些事情而设计您的应用程序。根据当前的实际需求（敏捷方式）设计应用程序，并在需要更改时重构代码 - 这是在市场上具有竞争力的唯一方法。功能出售的是您的软件，而不是其开放式架构以进行任何类型的更改（好吧，也有例外，但在这种情况下，开放式架构是最高级别的要求）。
使用 EF 时，您有多种选择如何创建实体：
如果您预计数据访问技术将来会发生变化，请使用 POCO 的第二种或第三种方法。对于 T4 模板，您可以简单地复制生成的 POCO 或修改项目文件，这样删除 EDMX 文件后就不会丢失它们。
如果您不确定第二种或第三种方法是否适合，请检查我对这些问题的回答：
因为我在某种程度上同意 @Patko 的答案，所以你还应该检查 Ayende 的博客。他写了几篇关于过度使用存储库和过度构建应用程序的文章。他正在撰写有关 NHibernate 的文章，但也可以使用 EF 做出类似的决定。唯一的区别是 NHibernate 提供了更好的抽象，因此直接使用 NHibernate 的代码具有更好的可测试性。
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.
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).
When using EF you have several choices how to create entities:
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:
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.
能够从一种持久性技术切换到另一种持久性技术固然很好，但您真的需要它吗？
首先，什么是存储库？ 根据 Fowler 的定义，它提供了对域对象的类似于内存中集合的访问。但每个现代 ORM 工具都已经做到了这一点，因此另一个抽象级别只会增加一点复杂性。
其次，从一种持久性技术切换到另一种持久性技术通常比仅仅提供另一种存储库实现更复杂。例如，您打算如何处理交易？事务通常取决于上下文并在存储库外部处理。您当然可以使用某种工作单元实现，但是您必须为每种持久性技术实现新的工作单元。
我并不是说你不应该使用存储库，只是也许再考虑一下。
Having the ability to switch from one persistence techonology to another is nice and all, but do you really need it?
First of all, what is a repository? By Fowler's definition it provides an in-memory collection-like access to domain objects. But every modern ORM tool already does that, so another level of abstraction just adds a bit more complexity.
Second, switching from one persistence technology to another is usually more complex than just providing another repository implementation. For instance, how do you intend to handle transactions? Transactions usually depend on context and are handled outside repositories. You could of course use some kind of unit of work implementation, but then you would have to implement new unit of work for every persistence technology.
I do not mean to say that you should not use repositories, just maybe give it another thought.
EF 设计器创建的实体类位于您的项目中的“Model.Designer.cs”内。您可以复制代码，以便即使您从 EF 中删除模型或引用，您的实体仍保留在项目中。
然而，它们与 EF 紧密耦合，因此您应该努力将 EF 与实体类解耦。
到目前为止，您拥有可以帮助您解耦的 T4 模板，但它们仍然需要对所选 T4 进行一些更改：
EF4.1 带来了一个简化的 API DbContext，当您想要解耦实体类时，它可以改善您使用 EF 的体验。使用 EF4.1，您可以获得 3 种方法：
，回答您的问题：
请参阅如何在此处完成所有这些操作：EF 4.1 模型和数据库首次演练。
您应该阅读 ADO.NET 团队博客 在 EF 功能 CTP5 中使用 DbContext 第 1 部分：简介和模型 （EF4.1 以前称为 EF 功能 CTP5） 。
您可以在我的问题中获取更多详细信息： EF仅 POCO 代码 VS 具有实体数据模型的 EF POCO。
The entity classes created by EF's designer are there in your project, inside your "Model.Designer.cs". You can copy the code so that your entities remain on your project even if you remove your model or the references from EF.
However, they are tightly coupled to EF, so you should strive for decoupling EF from your entity classes.
Until now, you had T4 templates that could help you with the decoupling, but they still would require some changes to the chosen T4:
EF4.1 brings a simplified API, DbContext, that improves your experience with EF when you want to decouple entity classes. With EF4.1 you get 3 approaches:
Now, answering your question:
See how you can do all this here: EF 4.1 Model & Database First Walkthrough.
You should read the series in ADO.NET Team Blog Using DbContext in EF Feature CTP5 Part 1: Introduction and Model (EF4.1 was formerly known as EF Feature CTP5).
You can get more details in my question: EF POCO code only VS EF POCO with Entity Data Model.
实体框架版本 4 中的新功能之一是“代码优先”开发。这将允许您将常规 C# (POCO) 类与实体框架一起使用。一旦您的类以这种方式编写，您就可以编写存储库的不同实现，使用不同的机制来持久保存这些类。
ScottGu 有一个 博客文章包含更多信息。
One of the new features in Entity Framework version 4 is "Code First" development. This will allow you to use regular C# (POCO) classes with entity framework. Once your classes are written this way, you could write a different implementation of the repository that persists those classes using a different mechanism.
ScottGu has a blog post containing more information.