[[426224]]

本文轉載自微信公眾號「DotNET技術圈」，作者Michael Hoagland。轉載本文請聯系DotNET技術圈公眾號。

前言

這是一個對話性的討論，它討論了一個嚴重的問題趨勢，我發現在由初級團隊到架構師團隊的各種規模的組織中，EntityFramework的利用率都很高。

這不是一個如何做的問題,這也不適合新手。如果有什么能激發您的想法，或者您對我提到的事情感到好奇，那么Google是您的朋友。這也是我的第一篇博客文章。歡迎批評。

歷史和功能介紹(按版本)

首先，讓我們簡單回顧一下EF隨時間推移推出的功能。這絕不是詳盡無遺的，當然也不會通過對主要版本的更新列出所有內容。它只是提醒了迄今為止EF的故事。

EF / EF 3.5

· DB First

EF 4.0

· Lazy Loading

· Migrations

· POCOs

EF 5

· Enums

· Spatial

EF 6

· Async

· Interception

· Logging

· NuGet Installation

· Recovery

EF 7 / Core

· Code First Only

· In-Memory Support

· Limited Batching

· Nonrelational Support

看到這種零散的發布以及Microsoft在開發領域的普遍聲譽，Entity Framework有了一個不好的驚喜，并不是因為它為我將要解決的問題找借口而已。根據您正在使用的次要版本，功能似乎隨機出現。因此，即使安裝了相同的主要版本，您仍會習慣某些東西，轉到另一個環境，提出聲明并在其現有框架上進行嘗試，即使它沒有安裝，您也仍然會“告訴您”的樣子有助于進一步加深已經確立的地位。

基本上，EF的典型故事如下：

高級人士：“讓我們使用EF和倉儲模式!”

其他開發人員：“ Idk，還沒聽說過好消息。”

高級：“不，太好了!看到這個例子嗎?”

開發人員：“嗯，好的。”

起初，它的工作原理在可接受的范圍內。然而，隨著它的增長，遲緩開始出現，人們開始抱怨。由于我們行業中償還技術債務的狀況非常糟糕，或者由于完全拒絕首先查看倉儲模式中的技術債務，因此，據稱聰明的人的整個部門都袖手旁觀，只是得出結論，”EF是垃圾"，并不是說他們的使用是垃圾。

我在這里要說明的是后者，并向您展示如何避免該陷阱。

EF使Sql過程抽象化

在我職業生涯的早期，我開始直接通過ADO使用經典的ASP和SQL Server。我在一個非常小的網絡部門工作，因此我經常不得不親自進入數據庫來創建表和執行任務。在一系列復制/粘貼部署，生產測試等過程中，我很快熟悉了SQL Server的所有技巧。“那這個呢?不會，該產品頁面仍然無法加載。那個怎么樣?!不，仍然無法加載。來吧...這個?成功!通過幾乎在黑暗中絆倒，我對索引，視圖，復制，安全權限等等非常了解，當時甚至還沒讀完高中。

使用結構化的環境輸入我的前幾個地方，然后使用Entity Framework時讓我非常臉紅。它完全沒有我習慣的任何選擇。因此，我跳上船，但是沒多久就開始抱怨。如果您有金魚的記憶，讓我重申我習慣于隨意調整所有杠桿。遇到問題時，我會進行調查。通常，我發現諸如索引利用率之類的關鍵組件被完全忽略了。當我提出這些問題時，我被告知EF因不知道如何利用它們而感到過失，而我們是在這里處理業務問題，而不是由Microsoft來為他們做。老實說，我基本上還是一個初級開發人員。我有什么理由不同意呢?

倉儲模式存在的問題

點擊訪問倉儲模式。倉儲模式的問題有兩個方面。存儲庫模式的問題有兩個方面。首先，它要求您預先聲明如何綁定應用程序與數據庫進行交互。即使您構建了這些超級復雜的方法，這些方法允許您傳入表達式、字典或異常動態，并且您很有創造力，但是您所做的只是制造了一個維護噩夢。

“但是調用者可以定義他們所需要的!” 不，他們不能。當然，他們可以指向實體并通常定義要選擇的數據的形狀，但是他們無法確定字段選擇之類的內容。他們沒有辦法說他們需要以一種友好的方式預先加載數據或延遲數據。他們不能在一次實例化中說他們也需要來自這里或那里的數據，但在下一次實例化中，他們只需要找到目標實體，除非神圣的存儲庫允許他們這樣做。相反，您會得到這些全有或全無的決策，這些決策將您的應用程序鏈接在一起，我們想知道為什么它會很快降級。我真的希望你的水晶球比我的好。

其次，即使是微軟自己的例子也沒有使用某些實習生可能編寫的適當接口。因此，我說，每個人都做錯了。關于EF的常識是使用存儲庫模式，由于存儲庫模式本身的文檔和示例不正確，所以沒有人會讓EF做它被設計用來做的事情，因為知識的來源受到了毒害。面對這種情況，我聽到很多人抱怨說MVC教程的例子直接使用了DbContext，抱怨說它不夠穩定，也不是說幾乎沒有人做得很穩定，但這是另一篇博客文章。(大多數軟件直接跳轉到ID，忽略了其他的。)

讓數據庫就只干數據庫的活

由于SQL Server是EF中最常用的支持數據存儲，因此它不是一個干凈的軟件。太亂了 ，它具有大量場景的功能。如果您想讓您的應用程序實際使用您所支付的巨額許可費用的一小部分，請停止將SQL約束到EF驅動的地獄荒原，而這些荒地比SELECT *還要好。然后，我們喜歡抱怨事情進展緩慢。

如果您不讓EF在正確的情況下利用功能，則可能無法意識到平臺的潛力。必須浪費數十億美元的許可和開發成本，即使在應用程序以截然不同的方式增長時，使用的獨特功能也只會使SQL Server的單位利用率下降。這是一種直覺，但是看到我在大型和小型公司中看到的愚蠢的樸素倉儲實現，很難在這里看到我是完全錯誤的。這對我們自己，我們的雇主和彼此都是有害的。

實體框架仍然逐步鎖定在基礎數據存儲的工作方式上。在SQL Server中，這意味著聯接性能，視圖和索引利用率，存儲過程調用等。這就像將乳膠手套稱為手的抽象。它不是，EF也不是它所依賴的存儲機制的抽象。相反，它是一組通用的API，它們使我們能夠以統一的方式訪問數據。由于我剛才所說的原因(我們不能以任何方式否認或減輕基礎實現的行為)，這不是一個抽象。因此，我們必須在代碼中考慮顯式或隱式破壞抽象的那些行為。如果要假裝它是抽象，我們唯一能做的就是把頭埋在沙子里，然后在事情變得笨拙時繼續continue吟。

最近，我提供一個架構師的建議：對讓數據庫定義視圖和將EF指向視圖而不是表，您知道，這讓dba能夠真正完成他們的工作，并使數據庫能夠在不破壞應用程序代碼的情況下進行更改。

這并不是什么難事，但問題是普遍存在的，所以大多數人在他們太熟悉的環境中都看不到過去。那么，我們該怎么做呢?

使用IQueryable而不是IEnumerable

正確使用Entity Framework的第一步是打破與IEnumerable的依賴關系。當談論斷開連接的商店時，這是很糟糕的。IEnumerable唯一給出的就是延遲執行。如果這是您想要脫離ORM的唯一功能，那么您就不需要ORM。IEnumerable隱瞞使用數據存儲的原因在于，它們一勞永逸地固定在它們的表示中。即使應用程序增長，即使倉儲中添加了新方法，返回IEnumerable的舊實現也對它們所處的新世界都是盲目，聾啞和愚蠢的。您實際上是在強迫代碼與數據布局和期望一起使用。就像幾年前首次實施時一樣。這是開發人員的錯，但應歸咎于EF。

但是，IQueryable可以變形并更改為其給定的上下文。即使傳遞和添加了子句，它也可以評估實例，例如各個調用的需求。如果DbContext已經獲取了數據，但它仍可以從高速緩存中檢索實體，然后才能以非常快的速度進行重復調用，從而使熱路徑更加涼爽。更重要的是，它還提供了一些功能，例如，如果基礎提供程序支持的話，讓我們流數據;無需實例化List對象以使其對堆更友好地加載數據;檢查基礎類型，以便我們可以在復雜的工作流程中做出明智的決定;訪問基礎上下文, 等等。

這些都是使您的代碼真正了解正在發生的事情而不會破壞抽象障礙的所有功能，因為EF不是抽象。順便說一句，抽象應該是使用EF的組件，而不是EF本身。我在程序員進行的許多討論中表達了自己的見解，這些討論表達了一些需求，但是我們以“抽象”的名義對許多解決方案solutions之以鼻，隨之而來的是我們高興地扭曲自己的箍，這樣我們就可以繼續存在固體。

開始習慣匿名類型

我聽說過的關于EF的最大的抱怨也許就是它檢索了多少該死的數據。誰定義實體?EF?沒有!你做到了 從本質上講，您不必多怪，因為每個表的實體似乎是所有人都可以看到的。盡管如此，無論實體有多大，我們都無需受到阻礙。將匿名類型傳遞給EF查詢將導致EF僅選擇您定義的字段。可以將數十列的“無法重構”的怪物表分解為實際需要的3或4個字段。一次選擇整個實體并假裝無能為力的迷戀只能描述為一種大眾歇斯底里的形式，我們大聲疾呼，“我看不到你!”

使用正確的工具完成工作

您知道所有帶有封面上各種工具的Microsoft Press書籍嗎?您知道，除了某些人只是選擇隨機圖像之外，還有一個原因。大多數工具不僅是螺絲起子或刨刀。有一些真正的奇怪應用沒有明顯的應用，但是可以肯定的是，它們有自己的目標，并且擅長于此。“正確的工具”的口號經常重復出現，但是我們并沒有真正停下來思考工作，更不用說工具了。以下是EF的一些功能。

自.Net 2.0以來出現的SqlBulkCopy

另一個與EF數據量密切相關的大型抱怨是，EF檢索到它據稱無法處理大量數據的方式。我喜歡開發人員的雙重性。我想讓您知道，結合下面討論的AsStreaming，反應性擴展和SqlBulkCopy，我可以在一分鐘內檢索，轉換和推送數百萬條記錄，而不會費力地創建一個完全基于任何工作負載的完全基于代碼的ETL解決方案從較小的記錄到中等大小的記錄(例如5–100億條記錄)，并且仍然具有良好的性能。如果您需要更多，則有更多專用工具。但是，不要說Entity Framework無法處理大量數據。您的代碼無法處理大量數據。EF很好。

可悲的是，自2005年以來我們就擁有SqlBulkCopy，但我們卻假裝工具箱中有這個大漏洞。問題已經解決。重新發明輪子的理由為零。你猜怎么了?它也支持流!

AsTracking與AsNoTracking

我覺得自己的成績很差。關于EF的另一個大抱怨是它的數據緩存。您幾乎總是可以告訴DbContext擺脫緩存的實體。不過，最近，我們獲得了將其設置為Entity Framework Core中默認策略的能力。相反，我們可以選擇要跟蹤的內容，而不是不需要的內容。我很高興地承認一個煩惱，即您仍然需要分離實體。

流式傳輸

實體框架中的查詢通常在返回之前緩沖所有結果。流技術解決了這一問題，并立即讓您開始處理數據進入應用程序的過程。您既可以更快地開始工作，又可以使服務器對內存更友好。

特殊雪花

在開發人員中，我看到了一個令人不安的趨勢。缺乏探索和發明的欲望。我們想要開箱即用的解決方案，在不了解細節的情況下“可行”。即使代碼不是魔術，我們仍然相信看不見的魔術。

我采用的一般方法不是構建這些固定的倉儲，而是構建擴展，使我們的應用程序以我們需要它們的獨特方式運行。是否希望在運行時間較長的過程中緩存數據的好處，但又不能在給定操作之外繼續存在呢?對于我來說，這聽起來像是DbContext的完美擴展方法，該方法可以獲取一些實體，對其進行處理以獲得緩存的好處，然后在返回之前清除緩存。另一種擴展方法是在操作完成后分離所有那些實體的方法。

不要害怕

我在這里談論DbContext是因為有很多人對待它。它被視為一件大，笨重，笨拙的事情，如果您不小心的話，它們會偷走您的孩子。我們花了很長的時間才能使DbContext的存在只為少數幾個組件所知。這將我們的實現進一步扼殺到倉儲中。由于我們必須遍歷倉儲以獲取任何類型的數據，因此我們需要在發生更改時定期違反“開放/關閉”原則，或者被迫接受倉儲指示的決策膨脹的折衷，并且在使用時要格外小心我們打電話給它。

釋放DbContext。如果模塊需要數據，請不要自欺欺人，說DbContext還不是依賴項。我可以向您保證，如果您對它的可訪問性感到滿意，并消除“人們犯錯了怎么辦?!”的神秘主義。它實際上將使我們整體上變得更好。如果某人可以提交頑皮的代碼，并且至少使它經過一次未經測試的生產，則您實際上就沒有發布控制或質量檢查。諸如隱藏DbContext之類的策略是您組織中已經流血的傷口上的權宜之計，無助于真正緩解實際問題。

別再找借口

 

我們程序員必須停止像解決我們所遇到的問題的解決方案那樣行動，或者必須使用node.js和dapper的正確組合來區分它們，這并不是說它們沒有合法用途，而是經常被他們當作替罪羊實體框架是一種很好的工具，可以用來做某事。我們十年來擁有的工具已經足以滿足我們的大多數需求。一次又一次的錯誤決定最終導致錯誤的決定，使我們陷入困境。使您的工具適應自如。嘗試新事物。可以肯定的是，我們只能怪自己。