摘要:N-Tiers開發方式(為何使用COM+元件的撰寫商業邏輯層)
在上一篇N-Tier方式開發(系統分析) 提到了商業邏輯層的開發，為何會選用COM+來處理，主要有兩個原因：
- 確保交易的完整性：可交由COM+支援Transaction的機制處理
- Web App切換身分執行元件
一、確保交易的完整性：
在確保交易的完整性，可以透過COM+對於Transaction的支援，讓拆解各功能的時候，不必特意的去考量Transation異動的部份，可交由COM+來處理
當一個商業邏輯中有了資料的維護，在邏輯的過程中可能會維護了超過兩個以上的資料表在不同的功能上。
舉個例子來說，例如：產生交易資料、扣除在庫資料，如果將這兩個動作處理在兩個元件上，我們分別稱作【COMA(產生交易資料)】與【COMB(扣除在庫資料)】，將此兩個動作分別放在不同的元件上，可以讓其他的功能來呼叫，而兩個動作，又必須完整的完成了，才能夠算是一個成功的交易過程，如果COMA或者COMB的程式運作過程中，有了什麼狀況(例如無在庫資料，無法扣除時)，那麼在這過程中維護的資料必須還原→此時這樣的還原動作可交給COM+自動完成
假設COMA中需要維護4個資料表，而COMB需要維護3個資料表，程式流程是
TBLA1--TBLA2--TBLA3-----→TBLB1--TBLB2--TBLB3┐
TBLB4←---------------------------┘
在COMA執行的過程中，維護了3個資料表(A1、A2、A3)時，呼叫COMB又維護了兩個(B1、B2)
此時要維護B3時出了問題，那嚜剛剛維護的(A1、A2、A3、B1、B2)資料通通要還原
只需將COMA與COMB包在一個交易中，那麼當過程中有其中一個失敗了，就會還原回去
如果又有另外一個元件COMC也會呼叫COMB的相同Function，那麼也只需將COMC與COMB包成一個交易，那麼就能夠當有問題的時候也自動還原回去
二、Web App切換身分執行元件
在Web App運作的過程中，透過IIS來使用應用程式，主要是透過【IUSER】這樣的使用者來運作，而IUSER這樣的使用者基本上在權限上是限制很多的，因此如果要存取非IIS的資料夾、存取資料庫，都不適合將權限開放給IUSER來使用，以免網路上的駭客透過IUSER竄進來做一些壞事。
然而系統又有時候必須讓Web的使用者在Server上執行一些特別的功能(例如資料庫的存取)，此時就可以透過COM+的Package來設定特別的識別帳號，然後開放這樣的帳號相關資料表的權限。這樣就能夠更靈活的設計我們的程式
三、介面與商業邏輯分離→資料庫轉換介面層可沿用
當介面與商業邏輯分離時，在ASP.NET中所設計的與資料庫之間的溝通是透過商業邏輯的元件，只需要元件的名稱不變、呼叫的函數不變、傳遞的參數不變，那麼假使要轉換不同的資料庫(例如Access轉成SQL)，介面層的相關程式都不需要修改，只需要修改商業邏輯的元件即可。
更進一步的，如果商業邏輯層中，把商業邏輯運算與資料庫存取也分開了，那麼要轉換資料庫的時候，也只需要把資料庫存取的相關元件修改後，就能夠快速的切換過去，不需要修改商業邏輯的運算部分。這讓整體系統在未來的擴充、轉換上有更大的彈性。
因為有這樣的特性，所以小喵才會以COM+元件來當作商業邏輯的開發。
以下是簽名：
- 歡迎轉貼本站的文章，不過請在貼文主旨上加上【轉貼】，並在文章中附上本篇的超連結與站名【topcat姍舞之間的極度凝聚】，感恩大家的配合。
- 小喵大部分的文章會以小喵熟悉的語言VB.NET撰寫，如果您需要C#的Code，也許您可以試著用線上的工具進行轉換，這裡提供幾個參考
| Microsoft MVP Visual Studio and Development Technologies (2005~2019/6) | topcat Blog:http://www.dotblogs.com.tw/topcat |
