遷移到實體框架自定義ORM

Question

我們目前有一個完全由ASP.NET和MVC手動編寫的解決方案。

DAL目前有很多醜陋的黑客攻擊和解決方法，而不是擴展這些黑客，我設法說服我們需要遷移到某種ORM。

對於團隊中的實體框架經驗，我們已決定使用實體框架，但是，對於任何可能有此經驗的人員，我都有一個遷移問題。

如果我們要將Entity-by-Entity遷移到一切都遷移到EF之後，會不會有任何性能問題？我們可能面臨哪些可能的障礙（除了必須重寫大部分BL的明顯情況）？實際上是否應該通過實體來實現（就創建模型而言），還是存在創建實體模型和逐位更改BL的問題。

我似乎無法找到關於這個問題的任何文檔.. MSDN似乎只是說「耶實體框架是好的，所以遷移到它是好的。」。

任何意見，將不勝感激。

PS：我沒有這樣說的：Migrating from 'native' OODBMS to ORM (Entity Framework/SQL Server)

然而，我們已經決定去與EF，而不是NHibernate的，它並不能證明是非常有用的。

Answer 1

這是個好問題，我從我的預期中得到了答案。這是關於'耶實體框架是好的，所以遷移到它是好的'

現在我們的團隊正在研究大（非常大）的人力資源SaaS解決方案。從一開始我們決定使用：

• EF 4.1
• 的MySQL（這是從客戶要求）
• .NET MVC 3

然後時間的推移（3個星期附近），我們注意到接下來關於EF：在我們的系統中，如果我們需要將來很難支持系統，那麼使用Model首先是不適用和有用的，例如，改變一點點db結構或者在表格之間建立新的關係。

在這種情況下，我們轉移到EF Code First（對於所有數據庫請求使用一個通用存儲庫）。這是導致它是如此新技術的風險，並且沒有關於大型解決方案的最佳實踐或使用案例。因此，我們收到了很多其他的頭痛：

• ORM提出了很多數據庫請求（導致表之間的關係很多）。修復由.Include（）
• POCO對象的動態代理 - 造成了很多麻煩，導致在代碼中的第一個實體從數據庫來的不像被請求的實體類型 - 像動態代理類型。所以當我們試圖序列化它們並將其放到反序列化的Memcached上時，我們得到了這個實體在當前上下文中不再可用的錯誤。像這樣固定：http://msdn.microsoft.com/en-us/library/dd456853.aspx和這個：http://blogs.dotnetkicks.com/dpeterson/2011/08/11/theres-a-proxy-in-my-boots-entity-framework-poco/
• 愚蠢的包與會員發送了很多令人難以置信的請求。通過檢查我們的工作與會員

此外，我們試圖NHibernate的只是比較性能固定。 NHiberanate具有相同的:)

一般信息，你應該知道關於EF：

• 如果你想武官第三部分緩存準備好解決方法。 NHibernate的有這個
• 原生集成有EF和NH性能之間沒有什麼大的不同，但新罕布什爾州有大量的手工工作與測繪

希望我的回答你的追問和信息是與您有關。

ps>對不起，我的英語:)