从LINQ迁移到SQL到实体框架4.0 - 提示，文档等 [英] Migrating from LINQ to SQL to Entity Framework 4.0 - Tips, Documentation, etc
问题描述
可以任何人都建议任何专门针对4.0和/或L2S迁移的资源？注意：我可以在.NET 3.5中找到大量有关从L2S迁移到EF的博客和文章，但我觉得很多这些博客和文章显然是过时的，对使用4.0的人来说无益。
$ b $我真的很喜欢像我可以得到的深刻的，底层的东西，我真的想离开感觉像我知道 EF 4.0我现在知道L2S 3.5的方式。
TIA！
我已经完成了这种非常类型的转换和FWIW的负载，我会说比起差异更多的相似之处。我不认为有任何明确的文件，将使您感觉像EF4的专家，除了已经在那里的东西之外...
http://msdn.microsoft.com/en-us/library/ex6y04yf （VS.100）.aspx
我能给你的是更明显的陷阱。具体来说，Linq2Sql想要将业务层和数据层组合得更加明显。它真的推动你创建自己的部分课程。我可以继续下去，但最具体的原因是一对一的映射器将为所有关系创建公共父和子属性。
如果您尝试对此模型使用任何类型的序列化，那么您将喜欢遇到循环引用问题，因为序列化程序从父级移动到子级，然后返回父级作为Linq2Sql序列化行为自动包含图中的所有子项。当您尝试抓住客户记录来检查名称属性并自动获取包含在图表中的所有相关订单记录时，这也可能非常烦人。您可以将这些父和子导航属性设置为public或internal，这意味着如果您想要访问它们，但不希望序列化程序自动创建循环引用，那么您几乎必须在部分访问它们class
一旦你启动了部分类路径，你通常只是继续该模式，最终将开始添加帮助方法来访问你的数据到你的各个实体类。此外，随着Linq2Sql DataContext更轻量化，您经常会发现人们在其上下文中使用某种类型的Singleton模式或Repository模式。你不会看到这么多的EF 3.5 / 4。
所以让我们说你有一些类似于所描述的环境，你想开始转换。那么，你需要知道DataContext何时被创建/销毁，有些人会使用using（）语句来启动每个Business Layer方法，并且在该方法的整个生命周期中使上下文几乎活着。显然，这意味着你可以进入一些需要在你的问题的最后添加.ToList（）或一些其他的扩展方法的毛茸茸的情况，你可以拥有一个完整的内存中的对象集合，传递给一个子方法或任何甚至甚至那么您可能会遇到一些问题，即尝试更新上下文中的实体，而不是最初从其中检索。
您还需要弄清楚如果没有明确处理数据操作，则将您的Linq2Sql部分类中的BusinessLogic并入另一个层。当你需要/不需要你的上下文时，这不会是痛苦的，但它是最好的。
接下来，你会想要处理与对象图形状况。由于延迟加载工作方式的差异（他们使得EF 4.0中的配置可以使其更像Linq2Sql），您可能需要检查Linq2Sql中图形中子对象的隐含使用实现并验证它现在不需要明确的.Include（）或.Load（）来获取图形中的子对象。
最后，你将需要一般地决定一个序列化解决方案。默认情况下，作为EF模型的一部分生成的DataContracts和DataMember属性可以很好地与WCF一起工作，但对于像旧的.asmx WebServices这样的XmlSerializer，并不是很棒。即使在这种情况下，如果您不需要通过电线序列化子对象，您也可能无法使用它。因为通常情况并非如此，如果您有更多的SOA，那么您将要迁移到WCF，这将增加一大堆机会，但会令人头疼。
为了处理部分类的情况，以及大量的DataContext甚至序列化问题，还有许多新的代码生成模板可用于EF 4.0。 POCO实体模板有很多人兴奋，因为它创建POCO类，正如你所期望的（麻烦是排除任何类或成员属性的WCF等）。此外，自我跟踪实体模型几乎解决了上下文问题，因为您可以传递您的实体，并让他们记住更新的时间和方式，因此您可以更自由地创建/处理上下文（如Linq2Sql）。另外一个好处是，这个模板是用于WCF的开发模板，也可以是像RIA Services或WCF Data Services这样的任何构建在WCF上的模板，所以它们具有[DataContract]，[DataMember]和[KnownType]属性。 / p>
以下是POCO模板的链接（不包括在开箱即用）：
（编辑：我不能发布两个超链接，所以只需访问visualstudio库网站并搜索ADO.NET C＃POCO实体生成器）
请确保阅读ADO.net团队博客上有关实现此链接。如果您属于WebService vs. WCF服务类别，您可能会喜欢将上下文和实体分成单独的项目/程序集。 添加服务引用...代理生成不会像以前一样使用添加Web引用...命名空间，因此您可能希望在客户端应用程序中实际引用您的实体类程序集，以便您可以排除类型从参考库或任何您的服务引用，所以你不会得到很多模糊的参考从多个服务使用相同的EF模型和暴露这些实体...
我知道这是漫长而漫长的，但是这些小问题对于我来说并不像以前一样使用context.EntityCollection.AddObject（）而不是context.EntityCollection.InsertOnSubmit（）和context.SaveChanges（）来代替of context.SubmitChanges（）...
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.
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.
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!
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
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.
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.
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.
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.
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..
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.
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.
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.
Here is a link to the POCO template (not included out of the box): (EDIT: I cannot post two hyperlinks, so just visit the visualstudio gallery website and search for "ADO.NET C# POCO Entity Generator")
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...
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到实体框架4.0 - 提示，文档等的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
