所以我聽說L2S正在成爲渡渡鳥的方式。我也發現，如果我使用L2S，我將不得不編寫相同代碼的多個版本來定位不同的架構，即使它們略有不同。我最初選擇L2S是因爲它可靠且易於學習，而EF 3當時還沒有準備好供公衆消費。關於如何在EF 4.1中映射覆雜POCO對象的體面資源？
在閱讀EF 4.1的許多讚美之後，我想我會做一個可行性測試。我發現EF 4.1是一個讓你頭腦發熱的野獸。數百種做同樣事情的方式令人費解地複雜化。如果您打算使用簡單的表到對象映射實體，但似乎工作正常，但複雜的POCO對象映射已成爲真正的PITA。沒有好的教程，而且存在的很少是非常基本的。
有很多關於學習EF 4.1基礎知識的博客，但我有一種感覺，他們故意避免高級主題。有沒有關於更復雜的映射場景的好教程？例如，獲取現有的POCO對象並將其映射到多個表中，或者持久保存由其他POCO對象組成的POCO對象？我一直聽到這是可能的，但還沒有找到任何例子。
EFv4.1是什麼意思？你的意思是過度使用代碼優先/流利API嗎？在這種情況下，主要是爲了簡單的映射場景。它提供了更多的L2S，但在高級映射方面仍然很少。
EF中可用的基本映射遵循基本規則：一個表=一個實體。實體可以是表示實體本身的主類的單個類或組合，也可以是映射字段集（複雜類型）的輔助類。
最先進的功能，你會用流利的EF-API或設計師得到的是：
Designer還提供
當使用基本或更高級的功能表可以僅在一個映射參與。
所有這些映射技術遵循非常嚴格的規定。你的班級和表格必須遵循這些規則才能使其工作。這意味着您不能採取任意POCO並將其映射到多個表，而不滿足這些規則。
這些規則只能用EDMX和先進的方法與高級技能=不流利的API，沒有設計師，但定義XML EDMX手動修改時加以避免。一旦你走這條路，你可以使用
這兩個功能允許您定義類從多個表中合併。這兩種映射技術的缺點是映射結果是隻讀的。使用這些技術時，您必須使用存儲過程來保存更改。
免責聲明：IMO EF 4.1以Code-First方法而聞名。以下大多數鏈接都指向關於以代碼優先的方式做東西的文章。我對DB-First或Model-First方法不太瞭解。
我從Mr. Manavi's blog瞭解了很多東西。特別是，Inheritance with code-first series對我來說充滿了新鮮事物。 This MSDN link也有一些關於不同映射場景的寶貴鏈接/信息。此外，我通過跟蹤或回答在SO上的entity-framework標籤問題來學習manu的東西。當我想嘗試一些新的複雜對象映射時，我盡我所能（根據我對EF的瞭解）創建正確的映射;但有時候，你面臨死衚衕。這就是上帝創建StackOverflow的原因。 :)
我經歷了一些他的錄像去了，這是很難理解他在說什麼。博客更好，但更多的是相同的。閱讀它是一個真正的大腦剋星。我想我會繼續使用Linq to Sql，因爲我可以使用生成的實體查詢數據庫，然後將其按入我的POCO對象中。還有的情況是，我有時需要將對象映射到一個字段中，這是我確信EF無法處理的場景。 –
應該用Nhibernate代替。其映射場景更復雜嗎？ –
NHibernate提供了更好的映射功能，但是與EF中的流利API或設計器相比，映射可能更復雜，但與沒有設計器支持的EF中手動維護EDMX相比更直觀。 –
正如我所提到的，對於Kamyar而言，EF 4並不適合我。我會堅持L2S。我不會使用它的簡單映射，而是執行查詢並將它們按摩到我的POCO對象中，因爲它們包含大量EF 4無法處理的聚合。包括NHibernate在內的技術都不能將對象映射到字段，如逗號分隔的字段。 –