在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
緣起承繼之前的【淺談多層式架構 (Multi Tiers)】與【透過COM+來變身(切換身分)執行】。我們這一篇要來講COM+中小喵覺得最精華的部分--COM+的【交易(Transaction)】支援。再分析系統後,我們可能會將各式各樣的商業邏輯寫成Function放在不同的Project裡面的Class中,並且會互相呼叫來完成要進行的商業邏輯。而在互相呼叫的過程中,就可能有必要將彼此包在一個Transaction中。我們這篇就是要來講不同的元件中的相互呼叫時,如何包起Transaction的各種方式。
何謂交易再說明之前,先來看一下網路上的說明(Transaction ACID) (資料引用自:http://www.probe.com.tw/Products/jlive_doc/transaction.html)
以上是蠻學術性的講法,交易簡單的說就是【全有或全無】,交易過程中,要就必須全部成立,否則就全部失敗,小喵舉個例子,假設元件A→(呼叫)元件B,這個過程被包在一個Transaction中,那麼
COM+的交易(Transaction)類型COM+的異動是設定在類別上,該類別為什麼樣,這個類別中的所有Function都是依照該類別的設定來運作,而設定時是直接撰寫在類別的宣告上,而交易可以有四種,分別為:(對照到元件服務所看到的中文)
不同的設定,將會影響元件呼叫元件時,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呼叫時,就會依照這樣的方式運作。而撰寫商業邏輯時,需要考慮未來將需要怎麼運作,給予正確的宣告。 |
请发表评论