[[426224]]

本文轉(zhuǎn)載自微信公眾號「DotNET技術(shù)圈」，作者M(jìn)ichael Hoagland。轉(zhuǎn)載本文請聯(lián)系DotNET技術(shù)圈公眾號。

前言

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

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

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

首先，讓我們簡單回顧一下EF隨時(shí)間推移推出的功能。這絕不是詳盡無遺的，當(dāng)然也不會(huì)通過對主要版本的更新列出所有內(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)域的普遍聲譽(yù)，Entity Framework有了一個(gè)不好的驚喜，并不是因?yàn)樗鼮槲覍⒁鉀Q的問題找借口而已。根據(jù)您正在使用的次要版本，功能似乎隨機(jī)出現(xiàn)。因此，即使安裝了相同的主要版本，您仍會(huì)習(xí)慣某些東西，轉(zhuǎn)到另一個(gè)環(huán)境，提出聲明并在其現(xiàn)有框架上進(jìn)行嘗試，即使它沒有安裝，您也仍然會(huì)“告訴您”的樣子有助于進(jìn)一步加深已經(jīng)確立的地位。

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

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

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

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

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

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

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

EF使Sql過程抽象化

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

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

倉儲(chǔ)模式存在的問題

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

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

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

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

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

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

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

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

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

使用IQueryable而不是IEnumerable

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

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

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

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

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

使用正確的工具完成工作

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

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

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

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

AsTracking與AsNoTracking

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

流式傳輸

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

特殊雪花

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

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

不要害怕

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

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

別再找借口

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