N-Tiers开发方式(为何使用COM+组件的撰写商业逻辑层)

 

在上一篇N-Tier方式开发(系统分析) 提到了商业逻辑层的开发，为何会选用COM+来处理，主要有两个原因：

1. 确保交易的完整性：可交由COM+支持Transaction的机制处理
2. Web App切换身分执行组件

一、确保交易的完整性：

在确保交易的完整性，可以透过COM+对于Transaction的支持，让拆解各功能的时候，不必特意的去考虑Transation异动的部份，可交由COM+来处理

当一个商业逻辑中有了数据的维护，在逻辑的过程中可能会维护了超过两个以上的数据表在不同的功能上。

举个例子来说，例如：产生事务数据、扣除在库数据，如果将这两个动作处理在两个组件上，我们分别称作【COMA(产生事务数据)】与【COMB(扣除在库数据)】，将此两个动作分别放在不同的组件上，可以让其他的功能来呼叫，而两个动作，又必须完整的完成了，才能够算是一个成功的交易过程，如果COMA或者COMB的程序运作过程中，有了什么状况(例如无在库数据，无法扣除时)，那么在这过程中维护的数据必须还原→此时这样的还原动作可交给COM+自动完成

假设COMA中需要维护4个数据表，而COMB需要维护3个数据表，程序流程是

 

COMA                                         COMB
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+组件来当作商业逻辑的开发。