linq-to-sql - 从LINQ到SQL到Entity Framework 4.0的迁移-技巧，文档等

Question

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

谁能提出任何针对4.0和L2S迁移的优质资源？注意：我可以在.NET 3.5上找到许多与从L2S迁移到EF有关的博客和文章，但是我觉得其中许多显然过时并且对使用4.0的人没有帮助。

我真的很想获得尽可能多的，深入人心的东西。我想像我现在了解L2S 3.5一样真正地了解EF 4.0。

TIA！

Answer 1

我已经完成了这种类型的转换和FWIW的加载，我想说的是相似之处多于差异。我认为除了已经存在的东西之外，没有任何权威性的文档可以使您像EF4专家一样...

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

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

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

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

因此，假设您具有与上述环境类似的环境，并且想要开始转换。好吧，您需要确定何时将创建/销毁DataContext……有些人只会使用using（）语句启动每个业务层方法，并在该方法的整个生命周期中使该上下文存活很多。显然，这意味着您会遇到一些麻烦的情况，这些问题需要在问题的末尾添加.ToList（）或其他扩展方法，您可以将对象的完整内存集合传递给子方法，甚至可以传递给子方法那么您可能会遇到尝试在最初不是从中检索实体的上下文中更新实体的问题。

您还需要弄清楚，如果Linq2Sql子类中未包含显式处理数据操作的大部分BusinessLogic，那么如何将它们整合到另一层中。当您确定何时需要/不需要您的上下文时，这并不是一件容易的事，但这是最好的。

接下来，您将要处理对象图的情况。由于延迟加载的工作方式不同（它们使它们在EF 4.0中可配置，使其对于需要的人表现得更像Linq2Sql），您可能需要从Linq2Sql检查图中子对象的任何隐式使用实现，并验证它现在不需要显式的.include（）或.Load（）来获取图中的子对象。

最后，您通常需要确定一个序列化解决方案。默认情况下，作为EF模型的一部分生成的DataContracts和DataMember属性与WCF兼容，而与用于诸如.asmx WebServices之类的XmlSerializer则完全不兼容。即使在这种情况下，如果您永远不需要通过网络序列化子对象，也可以摆脱它。由于通常情况并非如此，因此，如果您拥有更多的SOA，您将希望改用WCF，这将增加很多新的机会，但令人头疼。

为了处理部分类的情况，以及沉重的DataContext甚至序列化问题，EF 4.0提供了许多新的代码生成模板。正如您所期望的那样，POCO-Entity模板在创建POCO类时引起了很多人的兴奋（麻烦是，它不包括WCF等的任何类或成员属性）。另外，自跟踪实体模型几乎可以解决上下文问题，因为您可以传递实体，让它们记住它们的更新时间和方式，因此可以更加自由地创建/处理上下文（如Linq2Sql）。另外一个好处是，该模板是WCF或WIA上建立的任何模板（如RIA Services或WCF Data Services）的入门模板，因此它们具有[DataContract]，[DataMember]和[KnownType]属性。

这是指向POCO模板的链接（未包含在包装盒中）：
（编辑：我无法发布两个超链接，所以只需访问visualstudio画廊网站并搜索“ ADO.NET C＃POCO实体生成器”）

确保阅读ADO.net团队博客上有关实现此链接的链接。如果您属于WebService vs. WCF Service类别，则可能需要将上下文和实体拆分为单独的项目/程序集。 “添加服务引用...”代理生成不会像以前的“添加Web引用...”那样处理名称空间，因此您可能希望实际在客户端应用程序中引用实体类程序集，以便“排除”引用库中的“类型”或服务引用上的任何内容，因此您不会从使用相同EF模型并暴露那些实体的多个服务中获得大量含糊的引用...

我知道这是漫长而漫长的过程，但是对我来说，这些小问题比起记住使用context.EntityCollection.AddObject（）而不是context.EntityCollection.InsertOnSubmit（）和context.SaveChanges（）而不是上下文，对我来说，更多的是麻烦。 SubmitChanges（）...