从 LINQ 迁移到 SQL 到 Entity Framework 4.0 - 提示、文档等 [英] Migrating from LINQ to SQL to Entity Framework 4.0 - Tips, Documentation, etc

问题描述

我在 .NET 3.5 SP1 中尝试了 EF，我是许多感到沮丧并决定学习 LINQ to SQL 的人之一.既然我知道 EF 是前进的选择"路径，再加上 EF 4.0 有一些令人兴奋的新功能，我想将我的应用程序迁移到 EF 4.0.

I tried out EF back in .NET 3.5 SP1, and I was one of the many who got frustrated and decided to learn LINQ to SQL instead. Now that I know EF is the "chosen" path forward, plus EF 4.0 has some exciting new features, I'd like to migrate my app to EF 4.0.

谁能推荐任何专门针对 4.0 和 L2S 迁移的好资源?注意:我可以找到大量与在 .NET 3.5 上从 L2S 迁移到 EF 相关的博客和文章，但我觉得其中许多显然已经过时并且对使用 4.0 的人没有帮助.

Can anyone suggest any good resources that are specifically targeted towards 4.0 and L2S migration? NOTE: I can find plenty of blogs and articles related to migrating from L2S to EF on .NET 3.5, but I feel like many of those were obviously dated and unhelpful to someone using 4.0.

我真的很喜欢尽可能多的深入、底层的东西；我想真正离开时感觉就像我了解 EF 4.0 就像我目前了解 L2S 3.5 一样.

I'd really like as much deep, under-the-hood stuff as I can get; I want to really come away feeling like I know EF 4.0 the way I currently know L2S 3.5.

TIA！

推荐答案

我已经完成了大量这种类型的转换和 FWIW，我会说相似之处多于不同之处.我认为没有任何明确的文档可以让您感觉自己是 EF4 的专家，除了已经存在的内容......

I have done loads of this very type of conversion and FWIW, I would say there are more similarities than differences. I don't think there is any definitive documentation that will make you feel like an expert in EF4, beyond the stuff that is already out there...

http://msdn.microsoft.com/en-us/library/ex6y04yf(VS.100).aspx

我可以给你的是更明显的陷阱".具体来说，Linq2Sql 想要更明显地将业务层和数据层结合起来.它确实促使您创建自己的部分类.我可以继续说下去，但最具体的原因是一对一映射器将为所有关系创建公共父子属性的方式.

What I can give you are the more obvious "gotchas." Specifically, Linq2Sql wanted to combine the business layer and the data layer a lot more obviously. It really pushed you to create your own partial classes. I could go on and on about way, but the most specific reason is the way the one-to-one mapper will create public parent and child properties for all relations.

如果您尝试对此模型使用任何类型的序列化，您会遇到循环引用问题，因为序列化程序从父级移动到子级，然后返回父级，因为 Linq2Sql 序列化行为会自动将所有子级包含在图.当您尝试抓取客户记录以检查名称"属性并自动获取图表中包含的所有相关订单记录时，这也可能非常烦人.您可以将这些父和子导航属性设置为公共"或内部"，这意味着如果您想访问它们，但不希望序列化程序自动创建循环引用，您几乎必须部分访问它们类.

If you attempt to use any type of serialization against this model, you will like run into circular reference problems as a serializer moves from a parent to a child and then back to the parent as the Linq2Sql serialization behavior automatically includes all children in the graph. This can also be really annoying when you try to grab a customer record to check the "Name" property and automatically get all the related order records included in the graph. You can set these parent and child navigation properties to be either "public" or "internal" which means if you want access to them, but don't want the serializers to automatically create circular references, you pretty much have to access them in partial classes.

一旦您开始使用部分类路径，您通常只需继续该模式，最终将开始添加用于访问您的数据的辅助方法到您的各个实体类中.此外，由于 Linq2Sql DataContext 更加轻量级，您经常会发现人们在他们的上下文中使用某种单例模式或存储库模式.对于 EF 3.5/4，您根本看不到这一点.

Once you start down the partial class path you generally just continue the pattern and eventually will start to add helper methods for accessing your data into your individual entity classes. Also, with the Linq2Sql DataContext being more lightweight, you often find people using some kind of Singleton pattern or Repository pattern for their context. You don't see this as much at all with EF 3.5 / 4.

假设您有一些与所描述的环境类似的环境，并且您想开始转换.好吧，您需要找出您的 DataContext 何时将被创建/销毁……有些人只会使用 using() 语句启动每个业务层方法，并让上下文在方法的生命周期内几乎一直存在.显然，这意味着您可能会遇到一些需要在问题末尾添加 .ToList() 或其他扩展方法的棘手情况，您可以拥有完全内存中的对象集合以传递给子方法或其他方法，甚至那么您可能会在尝试在最初未从中检索到的上下文中更新实体时遇到问题.

So let's say you have some environment similar to the one described and you want to start converting. Well, you need to find out when your DataContext is going to be create/destroyed...some people will just start each Business Layer method with a using() statement and let the context pretty much live for the lifetime of the method. Obviously this means you can get into some hairy situations that require adding .ToList() or some other extension method to the ends of your questions you can have a fully in-memory collection of your objects to pass to a child method or whatever and even then you can have problems with attempting to update entities on a context that they weren't originally retrieved from.

如果没有明确处理数据操作，您还需要弄清楚在您的 Linq2Sql 部分类中合并的 BusinessLogic 有多少进入另一层.当您确定何时需要/不需要您的上下文时，这不会是轻松的，但这是最好的..

You'll also need to figure out how to much of the BusinessLogic incorporated in your Linq2Sql partial classes out into another layer if it doesn't deal explicitly with the data operations. This will not be painless as you figure out when you need/don't need your context, but it is for the best..

接下来，您将要处理对象图情况.由于延迟加载的工作方式不同(他们在 EF 4.0 中对其进行了配置，使其行为更像 Linq2Sql，对于那些需要它的人)，您可能需要检查来自 Linq2Sql 的图中子对象的任何隐含用途实现并验证它现在不需要显式 .Include() 或 .Load() 来获取图中的子对象.

Next, you will want to deal with the object graph situation. Because of the difference in the way lazy-loading works (they made this configurable in EF 4.0 to make it behave more like Linq2Sql for those who wanted it) you will probably need to check any implied uses of child objects in the graph from your Linq2Sql implementation and verify that it doesn't now require an explicit .Include() or a .Load() to get the child objects in the graph.

最后，您需要决定一般的序列化解决方案.默认情况下，作为 EF 模型的一部分生成的 DataContracts 和 DataMember 属性在 WCF 中工作得很好，但对于用于旧的 .asmx WebServices 之类的 XmlSerializer 则完全不适用.即使在这种情况下，如果您永远不需要通过网络序列化子对象，您也可以逃脱它.由于通常情况并非如此，如果您有更多的 SOA，您会想要转移到 WCF，这将增加全新的机会，但又会令人头疼.

Finally, you will need to decide on a serialization solution in general. By default, the DataContracts and DataMember attributes that are generated as part of an EF model work great with WCF, but not at all great with the XmlSerializer used for things like old .asmx WebServices. Even in this circumstance you might be able to get away with it if you never need to serialize child objects over the wire. Since that usually isn't the case, you are going to want to move to WCF if you have a more SOA, which will add a whole new host of opportunies, yet headaches.

为了处理部分类的情况、庞大的 DataContext 甚至序列化问题，EF 4.0 提供了许多新的代码生成模板.正如您所期望的那样，POCO-Entity 模板在创建 POCO 类时让很多人感到兴奋(问题在于排除了 WCF 等的任何类或成员属性).此外，自跟踪实体模型几乎解决了上下文问题，因为您可以传递您的实体并让它们记住它们何时以及如何更新，因此您可以更自由地创建/处理您的上下文(如 Linq2Sql).另一个好处是，此模板是 WCF 或任何基于 WCF 构建的模板(如 RIA 服务或 WCF 数据服务)的首选模板，因此它们已经确定了 [DataContract]、[DataMember] 和 [KnownType] 属性.

In order to deal with the partial classes situation, and the hefty DataContext and even the serialization issues, there are a number of new code-generation templates available with EF 4.0. The POCO-Entity template has a lot of people excited as it creates POCO classes, just as you'd expect (the trouble is that excludes any class or member attributes for WCF etc etc). Also, the Self-Tracking Entities model pretty much solves the context issue, because you can pass your entities around and let them remember when and how they were updated, so you can create/dispose your contexts much more freely (like Linq2Sql). As another bonus, this template is the go-to template for WCF or anything that builds on WCF like RIA Services or WCF Data Services, so they have the [DataContract], [DataMember], and [KnownType] attributes already figured out.

这是一个指向 POCO 模板的链接(不包含在开箱中):(我不能发布两个超链接，所以只需访问visualstudio 画廊网站并搜索ADO.NET C# POCO 实体生成器")

Here is a link to the POCO template (not included out of the box): ( I cannot post two hyperlinks, so just visit the visualstudio gallery website and search for "ADO.NET C# POCO Entity Generator")

请务必阅读 ADO.net 团队博客上有关实现此功能的链接.如果您属于 WebService 与 WCF 服务类别，您可能会喜欢将上下文和实体拆分为单独的项目/程序集.添加服务引用..."代理生成不像添加 Web 引用..."那样处理命名空间，因此您可能希望在客户端应用程序中实际引用您的实体类程序集，以便您可以排除"引用库中的类型"或您的服务引用中的任何内容，这样您就不会从使用相同 EF 模型并公开这些实体的多个服务中获得大量模棱两可的引用...

Be sure to read the link on the ADO.net team blog about implementing this. You might like the bit about splitting your context and your entities into separate projects/assemblies if you fall into the WebService vs. WCF Service category. The "Add Service Reference..." proxy generation doesn't do namespaces the same way "Add Web Reference..." used to, so you might like to actually reference your entity class assembly in your client app so you can "exclude types from reference libraries" or whatever on your service references so you don't get a lot of ambiguous references from multiple services which use the same EF model and expose those entities...

我知道这很长而且很乱，但这些小问题对我来说比记住使用 context.EntityCollection.AddObject() 而不是 context.EntityCollection.InsertOnSubmit() 和 context.SaveChanges() 更重要context.SubmitChanges()...

I know this is long and rambling, but these little gotchas were waaay more of an issue for me than remembering to use context.EntityCollection.AddObject() instead of context.EntityCollection.InsertOnSubmit() and context.SaveChanges() instead of context.SubmitChanges()...

这篇关于从 LINQ 迁移到 SQL 到 Entity Framework 4.0 - 提示、文档等的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！