前言

這是一個對話性的討論，它討論了一個嚴重的問題趨勢，我發(fā)現(xiàn)在由初級團隊到架構(gòu)師團隊的各種規(guī)模的組織中，EntityFramework的利用率都很高。

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

歷史和功能介紹（按版本）

首先，讓我們簡單回顧一下EF隨時間推移推出的功能。這絕不是詳盡無遺的，當(dāng)然也不會通過對主要版本的更新列出所有內(nèi)容。它只是提醒了迄今為止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

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

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

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

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

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

開發(fā)人員：“嗯，好的。”

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

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

EF使Sql過程抽象化

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

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

倉儲模式存在的問題

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

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

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

讓數(shù)據(jù)庫就只干數(shù)據(jù)庫的活

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

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

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

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

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

使用IQueryable而不是IEnumerable

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

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

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

開始習(xí)慣匿名類型

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

使用正確的工具完成工作

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

自.Net 2.0以來出現(xiàn)的SqlBulkCopy

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

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

AsTracking與AsNoTracking

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

流式傳輸

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

特殊雪花

在開發(fā)人員中，我看到了一個令人不安的趨勢。缺乏探索和發(fā)明的欲望。我們想要開箱即用的解決方案，在不了解細節(jié)的情況下“可行”。即使代碼不是魔術(shù)，我們?nèi)匀幌嘈趴床灰姷哪g(shù)。

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

不要害怕

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

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

別再找借口

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

總結(jié)

以上是生活随笔為你收集整理的一些有关使用EF的错误用法展开的思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。