我是新來的實體框架，當然，我已經發現幾個關於SOF的問題與目標用例有關。什麼時候應該使用實體框架？
讓我給你一些信息。我沒有處理不同的數據庫供應商或不同的數據庫;一個且只有一個，SQL Server 2008和數據庫少於30個表。我是否真的需要重做一些東西並使用Entity Framework？
編輯：
感謝詹姆斯解決我的問題。所以我假設使用EF加起來的開銷，並做了一些工作，我不會知道的背景。這是MS的工作風格，所以我想我的下一個問題是：
它也會影響性能嗎？
它支持hierarchyid數據類型嗎？
其 最重要的功能如下：
默認情況下，它會自動從模型生成的類和 隨時動態更新這些類模型的變化。
它負責所有的數據庫連接，因此 開發人員不需要爲與數據庫交互的大量代碼編寫 。
它提供查詢模型的常用查詢語法，而不是數據庫的 ，然後將這些查詢轉換爲數據庫可以理解的查詢。
它提供了一種跟蹤對模型對象 進行更改的機制，因爲它們在應用程序中使用，並處理數據庫的更新 。
感謝您的簡單解釋:-) – Sha 2012-10-01 23:07:15
的主要原因是使用實體框架（或任何其他對象 - 關係映射器等的LINQ to SQL，NHibernate的等等），就是以簡化應用程序的數據訪問。藉助EF，您只需將新值分配給.NET對象，即可獲得通過LINQ查詢和簡單更新的功能，而無需自己編寫任何SQL代碼。
個人而言，我使用EF Code First和EF Migrations進行綠色領域開發，並在我有現有數據庫的情況下使用LINQ to SQL。
+1用於突出顯示綠地和現有代碼之間的差異。如果你想引入一個現有的代碼庫的理智，不要爲了EF而連根拔起。使用LINQ to SQL。 – 2012-07-14 19:38:25
的ORM對象關係映射器應該如果你正在做交互式數據操作可以使用如的EntityFramework，典型的OLTP應用程序可以在需要VS使用類似的代碼行數獲得大的減少普通的ADO.NET API（使用動態SQL或存儲過程調用）。ORM確實有性能損失，但是在交互系統中，這種性能損失一方面可以忽略不計，另一方面由於「咕嚕聲」的大幅度減少，另一方面，因爲產生最大性能損失的元素是人與系統
如果交互，你需要做的複雜的東西將運行從某些表採取的東西，並把它變成其他表沒有任何交互式用戶干預，則性能比較重批處理另一方面ORM方法的懲罰變得明顯，在這種情況下，它可以避免將數據庫內存空間取出來，並且使用存儲過程的性能優勢最終變得明顯。
所以一般：
_redo things_我們怎樣才能知道，如果我們不知道是什麼_do_是或你打算做什麼？ – 2012-07-14 21:55:36