从LINQ迁移到SQL到实体框架4.0 - 提示，文档等

我试用过EF .NET 3.5 SP1，而我是其中一个感到沮丧并决定学习LINQ to SQL的人。现在我知道EF是前进的“选择”路径，再加上EF 4.0有一些令人兴奋的新功能，我想将我的应用程序迁移到EF 4.0。从LINQ迁移到SQL到实体框架4.0 - 提示，文档等

任何人都可以提出任何好的资源，专门针对4.0 和 L2S迁移？注意：我可以找到许多与从.NET 3.5迁移到EF相关的博客和文章，但是我觉得其中很多人明显过时并且无助于使用4.0的人。

我真的很喜欢我能得到的深入内在的东西;我想真的走过来，感觉就像我知道 EF 4.0我现在知道L2S 3.5的方式。

TIA！

来源

2010-06-04 pbarranis

我已经完成了这种非常类型的转换和FWIW的加载，我会说有更多的相似之处比差异。我不认为有任何明确的文件，这将让你感觉像在EF4的专家，如果超过了已经在那里的东西...

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

我可以给你更明显“陷阱”。具体来说，Linq2Sql想要更明显地将业务层和数据层结合起来。它真的推动你创建你自己的部分类。我可以继续前进，但最具体的原因是一对一映射器为所有关系创建公共父项和子项目的方式。

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

一旦你开始部分类路径，你通常只是继续该模式，并最终将开始添加帮助器方法来访问你的数据到你的个人实体类。而且，随着Linq2Sql DataContext更加轻量级，您经常会发现人们在其上下文中使用某种Singleton模式或Repository模式。对于EF 3.5/4，您看不到这一点。

因此，假设您的环境与所述环境类似，并且您想开始转换。那么，你需要知道什么时候你的DataContext将被创建/销毁......有些人只需用using（）语句启动每个业务层方法，并让该上下文在方法的整个生命周期中保持活跃。很明显，这意味着你可以进入一些需要添加.ToList（）或其他扩展方法到问题结尾的多毛情况，你可以有一个完整的内存中的对象集合传递给子方法或任何，甚至那么您可能会尝试更新它们最初没有从中检索到的上下文中的实体。

如果没有明确处理数据操作，您还需要弄清楚如何将大部分BusinessLogic集成到Linq2Sql部分类中的其他层中。当你需要/不需要你的上下文时，这将不会是无痛苦的，但它是最好的。

接下来，你会想要处理对象图的情况。由于延迟加载工作的方式不同（他们在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服务或WCF数据服务一样在WCF上构建的任何模板，因此它们已经计算出[DataContract]，[DataMember]和[KnownType]属性。（编辑：我不能发布两个超链接，所以只需访问Visualstudio图片库网站并搜索“ADO.NET C＃POCO实体生成器”）。）

请务必阅读ADO.net团队博客上有关实现此操作的链接。如果您陷入WebService vs. WCF服务类别中，您可能会喜欢将上下文和实体分解为单独的项目/程序集。 “添加服务引用...”代理生成不会以与“添加Web引用...”相同的方式执行名称空间，因此您可能希望在您的客户端应用程序中实际引用实体类程序集，以便“排除类型从参考库“或任何您的服务引用，所以你不会从多个服务使用相同的EF模型，并暴露这些实体得到很多模棱两可的引用...

我知道这是漫长而漫长的，但这些小陷阱是waaay更多的问题，而不是记住使用context.EntityCollection.AddObject（）而不是context.EntityCollection.InsertOnSubmit（）和context.SaveChanges（）而不是context.SubmitChanges（）...

来源

2010-06-14 16:47:42 fdfrye