在三層架構的B層應用TransactionScope事務
一說到事務大家都會想到在儲存過程中使用事務,這樣可以保證多表操作時的資料一致性。但是三層架構中D層的方法很多都是針對單表操作的,與之對應的資料庫儲存過程一般也只涉及到關係密切的幾個表而已。但是當我們的B層業務需要對很多表進行操作時,用儲存過程來保證事務性顯得靈活性不夠。那麼怎樣才能在B層使用事物呢?
我上網查過很多資料,大部分都是用SqlTransaction這個類來在程式程式碼中保證事務性,但是SqlTransaction是與SQL Server資料庫相關的類,如果將這個類用在了B層,那麼就突破了三層架構的底線了,如果將來換資料庫(比如從SQL Server換到Oracle),D層和B層都得重寫,所以這樣做的侷限性很大。
後來我在網上查到了一個輕量級的事物類TransactionScope,這個類是與具體資料庫無關的類,用這個類來保證B層的事務性十分可行。
下面說一下這個類的基本用法
在TransactionScope中預設的事務級別是Serializable,即在事務過程中,完全性鎖表。別的程序不能查詢,修改,新增,刪除。這樣會導致效率大大降低,雖然資料完整性很高。通常我們不需要那麼高的資料完整性。所以需要修改預設的事務級別:
通過TransactionOptions類來改變事物的級別
TransactionOptions option = new TransactionOptions(); option.IsolationLevel = System.Transactions.IsolationLevel.ReadCommitted;
然後用option作為TransactionScope的建構函式的引數就可以建立低級別的TransactionScope物件了
using(TransactionScope scope=new TransactionScope(TransactionScopeOption.Required,option))
{
//此處為需要保證事務性的多個方法
if(方法全部執行成功)
{
scope.Complete();//提交事務
}
}
注:方法是否執行成功可以通過方法的返回值來判斷,因為B層呼叫D層的方法返回的一般都是bool值,所以只要所有的方法返回值都是true,那麼就可以提交事務了,否則將不提交事務,using中的程式碼相當於沒有被執行一樣
相關推薦
在三層架構的B層應用TransactionScope事務
一說到事務大家都會想到在儲存過程中使用事務,這樣可以保證多表操作時的資料一致性。但是三層架構中D層的方法很多都是針對單表操作的,與之對應的資料庫儲存過程一般也只涉及到關係密切的幾個表而已。但是當我們的B層業務需要對很多表進行操作時,用儲存過程來保證事務性顯得靈
MVC與B/S,C/S結構,三層架構/兩層架構 的關係
MVC是指Model模型,View檢視和Control控制器,也就是業務邏輯,介面和使用者輸入,這樣劃分系統比較清晰,這是設計人員要考慮的事。 什麼是C/S結構。C/S (Client/Server)結構,即大家熟知的客戶機和伺服器結構。它是軟體系統體系結構,通過它可以充分利
Entity Framework 三層架構--持久層使用封裝之實體模型
Entity Framework的橫空出世確立了其在.net領域官方ORM中的霸主地位,給我們開發者帶來了福音,但是使用使用上還是有些不便捷的地方,尤其是在三層架構的專案中,在業務層不容許出現直接操作ObjectContext 的情況下,需要針對不同實體編寫不同DAO的工作
B/S三層架構[轉載]
三層架構(3-tier application) 通常意義上的三層架構就是將整個業務應用劃分為:表現層(UI)、業務邏輯層(BLL)、資料訪問層(DAL)。區分層次的目的即為了“高內聚,低耦合”的思想。 1、表現層(UI):通俗講就是展現給使用者的介面,即使用者在使用一個系統的時候他的所見所得。
.NET應用架構設計—面向查詢的領域驅動設計實踐(調整傳統三層架構,外加維護型的業務開關)
閱讀目錄: 1.背景介紹 2.在業務層中加入核心領域模型(引入DomainModel,讓邏輯、資料有家可歸,變成一個完整的業務物件) 3.統一協調層Application Layer(加入協調層來轉換DomianModel) 4.從資料扁平結構轉換成OO體系結構(使用OO豐富程式碼結構) 5.D
簡單區分軟體開發中幾個概念:C/S結構和B/S結構、三層結構和兩層結構、MVC和三層架構
C/S——客戶端/服務端,簡單講就是客戶端電腦上需要安裝專有的軟體來更伺服器交流,就像QQ。主要通過訊息的機制傳遞(當然也可以自己寫協議,遊戲就是這樣做的。) B/S——瀏覽器/服務端,你只要有瀏覽器就可以與伺服器進行通訊,不用再安裝專門的客戶端,通訊協議使用HTTP協議.
橋接模式的應用之三層架構中的業務邏輯層(BLL)與資料訪問層(DAL)的解耦
各層的作用 ①使用者介面層:只負責顯示和採集使用者操作。 ②業務邏輯層:負責UI和DAL層之間的資料交換,是系統架構中體現核心價值的部分。它關注點主要集中在業務規則的制定、業務流程的實現和業務需求的有關係統設計。它與系統所對應的領域(Domain)有關。也可以做一些如使用
三層架構
持久層 保存 架構 一個 成對 調用 更新 部分 數據 三層架構:持久層:完成內存數據和磁盤數據的轉換。 采用DAO模式,建立實體類和數據庫的表作映射,也就是哪個類對應哪個表,哪個屬性對應哪個列,而持久層 的目的就是完成對象數據和關系數據的轉換。 業務層:完成業務處理。將表
三層架構設計理念
表現層 原則 視圖 內存 數據 轉換 數據庫 以及 展示 1、持久層:完成內存數據和磁盤數據的轉換,設計原則,一個實體類,一個持久接口,一次數據庫操作,一個持久方法 2、業務層:完成業務處理,將表現層提供數據處理後,交由持久層完成數據的保存,設計原則,一個實體類,一個業務接
什麽是三層架構?
aid 接收 mbed 連接 工具 樣式 邏輯 同時 規則 什麽是三層架構? 三層體系結構是在客戶端和數據庫之間加入了一個“中間層”,這裏所說的三層體系是指邏輯上的三層,即把這三個層放置到一臺機器上。 三層體系的應用程序將業務規則、數據
MVC三層架構
接口 ttr 視圖 回寫 業務邏輯層 命名規範 cti bean 文件路徑 需求: 註冊登錄; # 知識補充; >> MVC模型; |-- M 模型; |-- V 視圖; |-- >> 基本概念; |-- 層級之間的調用關系
三層架構—簡析
表示 現在 show lpar object 數據庫連接 打開 str 好的 三層學習完了,第一次驗收的時候,自己理解的也不是非常到位,後來又又一次敲了一遍登陸樣例,查閱了一些資料 進行第二次驗收才感覺清晰了很多。之前畫時序圖時我就想過時序圖基本上也是非常
.NET MVC與三層架構
增刪改查 ews 數據的操作 求反 註意 image http pla 業務 雖然接觸了兩者有一段時間了,但是有時還是會混淆概念,在此處不打算說明二者的區別,因為二者都是架構模式,並且也有一定的共存度,在實際開發中,嚴格區分意義不大。基於最近涉及到這部分知識就在復習下,編程
溫故而知新---淺析三層架構(一個超簡單的系統登錄三層架構實例)
lda code windows comm 面向 box reader 業務 兩個 剛開始接觸三層架構是在快兩個月前,那時候找了好多例子感覺也都看不怎麽懂,今天閑著沒事,就把以前學的東西翻出來,算是溫習溫習。由於本人也接觸時間不長,所以以下言論有不正確之處,多多
利用Dapper ORM搭建三層架構
程序 per flow tac 效率 接口 dap 數據訪問層 dapper 利用Dapper關系對象映射器寫的簡單的三層架構。Dapper:StackOverFlow在使用的一個微型的ORM,框架整體效率較高,輕量級的ORM框架。網上有較多的擴展。此處只是簡單的調用Dap
搭建連接MySql的三層架構的ASP.NetCore2.0的WebApi
tof pri result conf see collect gin 允許 sset 裏我們用三層架構搭建一個連接MySql的ASP.netCore模板的WebApi項目 首先添加WebApi項目(ASP.NetCore版本) 右鍵解決方案>新建項目>
CDD應用層架構學習總結
.cn src width hand sta ray del mrp 分享 怎麽樣用context,把數據、view和業務串起來的? 例如:聊天頁面,輸入框view產生的“hello”文本,直接通過context傳遞到BusinessObject進行處理,生成的新消息mes
關於C#三層架構增刪改查中的“刪除”問題
正在 font com 時間 convert strong int32 ring 三層架構 序: 剛學習C#,經過一段時間學習,現在正在做一個簡單的前後臺聯通的項目(主要是C#三層架構實現增刪改查)。分享一點兒小經驗,也供自己以後可以回頭看看自己的碼農之路。 內容: 主要分
關於C#三層架構增刪改查中的“查詢”問題
可能 一行 rep tro spa 結束 簡單 問題: .get 序:問題總是反復出現,可能只是一個小小的問題,但是就像肉中刺。 問題: 關於“姓名”字段的拼接問題 姓名字段的拼接:this.Repeater1.DataSource = db.GetList(" UNa
MVC與三層架構
html 創建 購物 傻瓜式 用戶名 djang 自己的 data 即使 三層架構和MVC 三層架構 (3-tier application) 是將整個業務應用劃分為:表現層(UI)、業務邏輯層(BLL)、數據訪問層(DAL)。區分層次的目的即為了“高內聚,低耦合”的思想。