實體框架vs直接數據訪問

Question

我一直使用直接數據訪問來處理過去的對象（手動運行查詢，並將結果映射到數據對象）。我知道微軟目前正在推動EF讓他們的客戶用來查詢數據對象。

我已經得到了社會的幾個問題，關於這個： -

• 如果你有一個複雜的數據庫，也就是幾百表，存儲過程，視圖像樣的數目，一切都在3NF。管理兩個模式（一個本地EF模式映射和一個數據庫）的負擔是否值得進行交易？

• 一旦你開始增加數據訪問，緩存如何比較兩者？我知道在直接訪問你可以實現你想要的任何形式的緩存，EF是否允許類似的東西？由於微軟在大力推動產品並讓人們爲它們編寫代碼（SQL-NS，Linq-to-Sql）之後對產品進行殺戮的歷史，EF如何應對這種情況？

正如我所說的，我目前大量使用的那一刻直接訪問，但考慮遷移（即新的查詢前進，而不是背棄他們都只是還沒有），並從尋找忠告其他人對他們的看法。

Answer 1

如果你有一個複雜的數據庫，即幾百個表，一個 大量的存儲過程，視圖，一切都在3NF。 負責管理兩個模式（一個本地EF模式映射和 一個數據庫）值得的權衡？

你可以使用自動化工具來保持你的EF模式是最新的，所以它不是那麼糟糕。

一旦你開始爬升數據訪問，如何緩存比較上 兩個？我知道在直接訪問你可以實現你想要的任何形式的緩存 ，EF是否允許類似的東西？

據我所知，是的。

鑑於後殺死大量的產品推 他們，讓人們爲他們寫微軟歷史（SQL-NS， LINQ到SQL）如何likley這是發生在EF？

這個問題太假了。

我與EF有關的問題是它的性能。是的，你得到了快速發展，但取決於業績。使用EF可以很容易地編寫一段糟糕而慢的代碼，如果你不能100％知道自己在做什麼，那麼以後可能會遇到一些嚴重的性能問題（特別是如果你處理數百個表） 。

我的建議是嘗試一些Micro-ORM框架，比如Dapper或Massive。您不會犧牲那麼多性能，但比傳統的Ado.net方法更容易維護。

但是，嘿，那只是我，你可能會愛上EF。

Answer 2

要記住與EF或任何其他ORM工具的事情是，它只是將東西（在EF和Linq2Entities情況下的Linq表達式樹）轉換爲SQL語句。由於在那裏有一個額外的抽象層和解析層，所以直接查詢會比較慢。但是開發人員通常更容易使用ORM。幸運的是，大多數ORM（特別是不確定EF）提供了一些仍然在需要時直接運行查詢的方式。

你提到有一個「複雜」的數據庫，這通常意味着有複雜的查詢。這是Linq不太喜歡的。例如，如果最終有查詢連接13個表，並且幾乎每個返回的列都被傳遞給一個db函數，並且有大量case語句和一些子選擇，那麼轉換爲Linq幾乎是不可能的。更簡單的做法是在視圖中包裝複雜性，並使用EF來查詢視圖。

另一方面，EF爲開發人員提供了智能感知，因爲真正的類被構建爲模仿數據庫。根據你的EF東西的佈局，你可以設置你的項目，使得所有的類都是從數據庫生成的，所以如果有人編輯數據庫模式，或者改變列數據類型，你的C＃代碼將會不再編譯。使用傳統的直接SQL查詢，直到運行時（或集成測試時間）纔會發現它。

這是所有的權衡......海事組織最好的做法是嘗試兩種方式，看看你更喜歡哪一種，或者以提供這兩種選擇的方式構建解決方案。在我工作的最後一個應用程序中，我有一個其他數據訪問類將使用的「數據庫工廠」類（工廠模式），他們可以向工廠請求一個普通的舊ADO.NET Command對象，或者詢問ORM對象（在EF情況下的上下文，但我使用SubSonic，所以相反，它是一個IQueryable實現）。這樣，您可以通過EF執行「簡單」查詢，並在SQL中執行「複雜」查詢。

Answer 3

與直接數據訪問相比，EF的主要優勢在於開發人員的生產力。

很少有開發人員再次編寫彙編代碼，我們讓編譯器生成它。隨着像EF這樣的工具變得更好，我們將更多地使用它們並停止編寫SQL。

但是，有時您需要額外的控制才能獲得所需的性能，因此您仍可能需要編寫一些SQL代碼。就像仍然有一些彙編代碼正在編寫一樣。

轉換工作的解決方案沒有商業價值。你可以試試EF進行新的開發。