承繼之前的【淺談多層式架構 (Multi Tiers)】與【透過COM+來變身(切換身分)執行】。我們這一篇要來講COM+中小喵覺得最精華的部分--COM+的【交易(Transaction)】支援。再分析系統後，我們可能會將各式各樣的商業邏輯寫成Function放在不同的Project裡面的Class中，並且會互相呼叫來完成要進行的商業邏輯。而在互相呼叫的過程中，就可能有必要將彼此包在一個Transaction中。我們這篇就是要來講不同的元件中的相互呼叫時，如何包起Transaction的各種方式。
緣起
承繼之前的【淺談多層式架構 (Multi Tiers)】與【透過COM+來變身(切換身分)執行】。我們這一篇要來講COM+中小喵覺得最精華的部分--COM+的【交易(Transaction)】支援。再分析系統後，我們可能會將各式各樣的商業邏輯寫成Function放在不同的Project裡面的Class中，並且會互相呼叫來完成要進行的商業邏輯。而在互相呼叫的過程中，就可能有必要將彼此包在一個Transaction中。我們這篇就是要來講不同的元件中的相互呼叫時，如何包起Transaction的各種方式。
何謂交易
再說明之前，先來看一下網路上的說明(Transaction ACID)
(資料引用自：http://www.probe.com.tw/Products/jlive_doc/transaction.html)
Atomicty 原子：不可部分完成性。如同原子一般，一個交易被視為最小的運作單位，不容許分割的完整個體，也就是說交易的處理只有成功執行或是不執行，沒有模糊地帶。
Consistency 一致：每個交易所造成的資料異動，必須滿足資料庫整體資料的一致性，否則將拒絕此異動作業，還原原始資料。
Isolation 隔離：隔離性，資料庫系統可以同時處理多個交易，每個交易之間應當具備循序能力(Serializability)，所以當一個交易尚未完成時，所異動的資料是不可以被其他交易使用，以免不確定性的異動結果造成其他交易的不正確處理結果。
Durability 耐久：持續性，利用交易所處理的異動，在交易尚未結束前，不會變動原始資料，只有當交易完成後，才會將異動反映到資料庫。此時即使發生系統故障，也不會影響異動後的資料。
以上是蠻學術性的講法，交易簡單的說就是【全有或全無】，交易過程中，要就必須全部成立，否則就全部失敗，小喵舉個例子，假設元件A→(呼叫)元件B，這個過程被包在一個Transaction中，那麼
- 剛開始還沒執行前，資料A=0，資料B=0
- 元件A改變了某一個資料A=1
- 元件B可以看到A=1，交易外面則是看到資料A被鎖定無法讀取
- 此時元件B改變資料B=1，元件A也可以看到資料B=1，交易外面看資料A,B被鎖定，無法讀取
- 元件B更改資料C=1時發生問題→觸發SetAbort→復原異動資料
- 復原後A=0,B=0且外部可以查詢A=0,B=0
COM+的交易(Transaction)類型
COM+的異動是設定在類別上，該類別為什麼樣，這個類別中的所有Function都是依照該類別的設定來運作，而設定時是直接撰寫在類別的宣告上，而交易可以有四種，分別為：(對照到元件服務所看到的中文)
- Disabled：停用
- NotSupported：不支援
- Supported：支援的
- Required：必要
- Requires New：需要新增
不同的設定，將會影響元件呼叫元件時，Transaction會如何包，如何運作。以下用來說明一下各個不同設定的意義：
元件呼叫元件的運作方式
在說明之前，以下會用一些圖形來代表Transaction運作的方式，先來看一下一些圖示的意義。方便理解接著的說明圖片。
接著來介紹各個不同設定的運作方式：
NotSupported(不支援)/Disabled(停用) : 無論呼叫他的元件是否有Transaction, 都不會有Transaction
Supported(支援的) : 依據呼叫的那個，前面無就無；前面有就有，而且會跟前面的包在一起。(支援前面的)
Required(必要) : 前面無，自己會產生一個；前面有，跟前面的包在一起。(最常用)
例如：A元件進行開立銷售傳票行程，此時呼叫B元件檢查庫存，並扣除可販數量，之後回到A元件，接著產生銷售傳票(Head/Detail)。這個過程是在不同的元件，卻完整包在一個Transaction中，全有或全無。中間過程有任何問題，會將全部過程Rollback。
Requires New(需要新增) : 無論前面有無，都會產生新的Transaction。(不會跟前面的包在一起)
例如：A元件接收批次訂單，產生了1000筆訂單，接著呼叫逐筆呼叫B元件，逐筆開立銷售傳票。產生訂單的A元件，與逐筆開立銷售傳票的B元件變成各自獨立的Transaction。如果是包成一個Transaction，那麼就變成必須這1000筆訂單都能成功出貨才能成立。但是訂單可以先成立，萬一開銷售傳票過程，遇到機種不足，該筆訂單不成功，卻可以繼續做下去，不影響1000筆訂單產生的過程。
透過以上圖片理解各種Transaction方式宣告的動作模式後。其實這些的Transaction動作只要宣告在Class上，那麼該Class就會依照這個宣告，在不同Class的Function呼叫時，就會依照這樣的方式運作。而撰寫商業邏輯時，需要考慮未來將需要怎麼運作，給予正確的宣告。
以下是簽名：
- 歡迎轉貼本站的文章，不過請在貼文主旨上加上【轉貼】，並在文章中附上本篇的超連結與站名【topcat姍舞之間的極度凝聚】，感恩大家的配合。
- 小喵大部分的文章會以小喵熟悉的語言VB.NET撰寫，如果您需要C#的Code，也許您可以試著用線上的工具進行轉換，這裡提供幾個參考
| Microsoft MVP Visual Studio and Development Technologies (2005~2019/6) | topcat Blog:http://www.dotblogs.com.tw/topcat |