EntityFrameworkCore進行讀寫分離的方式是什么

這期內(nèi)容當中小編將會給大家?guī)碛嘘PEntityFramework Core進行讀寫分離的方式是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

成都創(chuàng)新互聯(lián)公司是創(chuàng)新、創(chuàng)意、研發(fā)型一體的綜合型網(wǎng)站建設公司，自成立以來公司不斷探索創(chuàng)新，始終堅持為客戶提供滿意周到的服務，在本地打下了良好的口碑，在過去的十多年時間我們累計服務了上千家以及全國政企客戶，如服務器托管等企業(yè)單位，完善的項目管理流程，嚴格把控項目進度與質(zhì)量監(jiān)控加上過硬的技術實力獲得客戶的一致贊譽。

什么是事務呢？我們可歸結為一句話：多個提交要么全部成功，要么全部失敗即同生共死，沒有臨陣脫逃者。

那么問題來了，用了事務有什么作用或者說有什么優(yōu)點呢？事務允許我們將相關操作組合打包，以確保應用程序數(shù)據(jù)的一致性。

那么使用事務又有何缺點呢？使用事務雖然確保了數(shù)據(jù)一致性等等，但是會影響性能，可能會造成死鎖。

那么問題又來了，既然有其優(yōu)缺點，那么我們是否可以手寫邏輯實現(xiàn)數(shù)據(jù)一致性呢？當然可以，我們可以模擬事務回滾、提交的效果，但是這也無法百分百保證。

調(diào)用SaveChanges方法是否在事務中呢？

首先我們在控制臺中進行如下數(shù)據(jù)添加，然后添加日志打印。

我們通過打印日志得知在調(diào)用SaveChanges方法時則包含在事務中進行提交，所以請那些可在項目中用到多表添加擔心出現(xiàn)問題就加上了如下開啟事務，這很顯然是多此一舉。

看到如上日志信息還不是更加確定是不是，我們再來看看在上下文中的context.Database.AutoTransactionsEnabled 方法，詳細解釋如下：

通過AutoTransactionsEnabled方法解釋得知：其默認值為True，也就意味著當調(diào)用SaveChanges方法將使用事務性提交。當然我們可以在上下文構造函數(shù)中設置是否全局禁用事務，如下：

在EF Core中我們什么時候會用到事務呢？如果是單一上下文，單一數(shù)據(jù)庫，那么事務跟我們沒啥關系，壓根不用管事務。如果是在單一數(shù)據(jù)庫使用多個上下文（跨上下文）或者多個數(shù)據(jù)庫，這個時候事務就閃亮登場了。

比如對于電商中的商品、購物車、訂單管理、支付、物流，我們完全可以實例化五個不同的上下文，此時將涉及到跨上下文操作使用事務保持數(shù)據(jù)一致性，當然這是針對在同一關系數(shù)據(jù)庫中?；蛘呤菍嵗簧舷挛亩啻蝸硎褂檬聞毡３謹?shù)據(jù)一致性。

可以參看官網(wǎng)的介紹《https://docs.microsoft.com/en-us/ef/core/saving/transactions》，沒什么看頭，都是針對同一數(shù)據(jù)庫操作，無非還是我所說的跨上下文、使用上下文結合底層DbConnection來使用事務共享連接等等 

稍微大一點的看點則是在EF Core 2.1中引入了System.Transactions，可指定隔離級別以及使用ambient transactions（查資料作用是存在多個事務，事務之間存在連接，如此一來將顯得整個作用域非常冗長，通過使用此事務則在特定范圍內(nèi)，所有連接都將包含在該事務中），在此就不占用篇幅介紹了。

和大家一樣我們最關心的是分布式事務，也就是使用不同上下文針對多個數(shù)據(jù)庫，但是遺憾的是直到EF Core 2.1還不支持分布式事務，因為.NET Core中相關APi也還不完善，繼續(xù)等待吧。

隨著流量的進入，數(shù)據(jù)庫將承受不可抗拒的壓力，單一數(shù)據(jù)庫將不再適用，這都是隨著項目的演變所帶來架構的迭代改變，這個時候就涉及到分庫，對于查詢的數(shù)據(jù)單獨作為一個數(shù)據(jù)庫，作為數(shù)據(jù)的更改也單獨用一個數(shù)據(jù)庫，再結合那些什么負載均衡等等，數(shù)據(jù)庫壓力也就減弱了許多。

只作查詢的數(shù)據(jù)庫我們稱之為從數(shù)據(jù)庫，對于數(shù)據(jù)庫更改的數(shù)據(jù)庫稱之為主數(shù)據(jù)庫，主-從數(shù)據(jù)庫（Master-Slave）數(shù)據(jù)的同步方式也有很多。

雖然我也沒接觸過，我們就利用SQL Server中的復制進行發(fā)布-訂閱來模擬演示還是可以的。我們來看看.NET Core Web應用程序如何實現(xiàn)讀寫分離。

額外加一句，項目中我也未用到，都是我私下的研究，方案行不行，合不合理可以一起探討。我們創(chuàng)建了兩個Demo數(shù)據(jù)庫，如下：

我們將Demo1作為主數(shù)據(jù)庫，Demo2作為從數(shù)據(jù)庫，接下來用一張動態(tài)圖演示創(chuàng)建復制發(fā)布-訂閱（每隔10秒發(fā)布一次）。

我們給出Demo1上下文，Demo2和其一樣，按照正常做法接下來我們應該在.NET Core Web應用程序中注入Demo1和Demo2上下文，如下：

然后我們創(chuàng)建Demo控制器，通過Demo1上下文添加數(shù)據(jù)，Demo2上下文讀取數(shù)據(jù)，如下：

我們看到通過Demo1上下文添加數(shù)據(jù)后重定向到Demo2上下文查詢到的列表頁面，到了10秒自動同步到Demo2數(shù)據(jù)庫，通過刷新可以看到數(shù)據(jù)顯示。

雖然結果如我們所期望，但是實現(xiàn)的路徑卻令我們不是那么如意，因為所用實體都是一樣的，只是說所連接數(shù)據(jù)庫不一樣而已，但是我們需要創(chuàng)建兩個不同的上下文實例，很顯然這不是最佳實踐方式。

那么我們?nèi)绾巫霾攀亲罴褜嵺`方式呢？接下來我們再來創(chuàng)建一個Demo3數(shù)據(jù)庫，表結構和Demo1、Demo2一致，如下：

接下來我們在.NET Core Web應用程序Demo1、Demo2上下文所在的類庫中創(chuàng)建如下擴展方法（方便有同行需要學習，給出Demo項目基本結構）。

我們暫且不去看為何這樣設置，我們只是添加上下文擴展方法，更改連接為Demo3的數(shù)據(jù)庫，然后接下來我們獲取博客列表時，調(diào)用上述擴展方法，請問：是否可以獲取到Demo3的數(shù)據(jù)或者說是否會拋出異常呢？我們依然通過動態(tài)圖來進行演示，如下：

一直以來我們認為利用 context.Database.GetDbConnection() 方法可以回到ADO.NET進行查詢。

但是我們通過實際證明，我們可以設置其他數(shù)據(jù)庫連接從而達到讀寫分離最佳實踐方式，免去再實例化一個上下文。

所以對于上述我們配置的Demo1和Demo2上下文，我們大可只需要Demo1上下文即主數(shù)據(jù)庫，對于從數(shù)據(jù)庫進行查詢，我們只需在Demo1上下文的基礎上更該連接字符串即可，如下：

接下來問題來了，那么為何更改Demo1上下文連接字符串就能轉(zhuǎn)移到其他數(shù)據(jù)庫查詢呢？就是為了解決讀寫分離免去實例化上下文即Demo2的情況，但是內(nèi)部是如何實現(xiàn)的呢？

因為EF Core內(nèi)部添加了方法實現(xiàn)IRelationalConnection接口，使得我們可以在已存在的上下文實例上重新設置連接字符串即更換數(shù)據(jù)庫，但是其前提是必須保證當前上下文連接已關閉。

也就是說比如我們在同一個事務中利用當前上下文進行更改操作，然后更改連接字符串進行更改操作，最后提交事務，因為在此事務內(nèi)，當前上下文連接還未關閉，所以再更改連接字符串后進行數(shù)據(jù)庫更改操作，將必定會拋出異常。

上述就是小編為大家分享的EntityFramework Core進行讀寫分離的方式是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

分享標題：EntityFrameworkCore進行讀寫分離的方式是什么
文章URL：http://bm7419.com/article28/pceecp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、建站公司、關鍵詞優(yōu)化、網(wǎng)站收錄、外貿(mào)網(wǎng)站建設、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)