從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