一．三層架構(gòu)圖 二．系統(tǒng)各層次職責 1.UI（User Interface）層的職責是數(shù)據(jù)的展現(xiàn)和采集，數(shù)據(jù)采集的結(jié)果通常以Entity object提交給BL層處理。Service Interface側(cè)層用于將業(yè)務或數(shù)據(jù)資源發(fā)布為服務（如WebServices）。 2.BL（Business Logic）層的職責是按預定的業(yè)務邏輯處理UI層提交的請求。 （1）Business Function 子層負責基本業(yè)務功能的實現(xiàn)。 （2）Business Flow 子層負責將Business Function子層提供的多個基本業(yè)務功能組織成一個完整的業(yè)務流。（Transaction只能在Business Flow 子層開啟。） 3．ResourceAccess層的職責是提供全面的資源訪問功能支持，并向上層屏蔽資源的來源。 （1）BEM（Business Entity Manager）子層采用DataAccess子層和ServiceAccess子層來提供業(yè)務需要的基礎數(shù)據(jù)/資源訪問能力。 （2）DataAccess子層負責從數(shù)據(jù)庫中存取資源，并向BEM子層屏蔽所有的SQL語句以及數(shù)據(jù)庫類型差異。 DB Adapter子層負責屏蔽數(shù)據(jù)庫類型的差異。 ORM子層負責提供對象－關(guān)系映射的功能。 Relation子層提供ORM無法完成的基于關(guān)系（Relation）的數(shù)據(jù)訪問功能。 （3）ServiceAccess子層用于以SOA的方式從外部系統(tǒng)獲取資源。 注： Service Entrance用于簡化對Service的訪問，它相當于Service的代理，客戶直接使用Service Entrance就可以訪問系統(tǒng)發(fā)布的服務。Service Entrance為特定的平臺（如Java、.Net）提供強類型的接口，內(nèi)部可能隱藏了復雜的參數(shù)類型轉(zhuǎn)換。 （4）ConfigAccess子層用于從配置文件中獲取配置object或?qū)⑴渲胦bject保存倒配置文件。 4．Entity側(cè)層跨越UI/BEM/ResourceManager層，在這些層之間傳遞數(shù)據(jù)。Entity側(cè)層中包含三類Entity，如下圖所示：  三．Aspect Aspect貫穿于系統(tǒng)各層，是系統(tǒng)的橫切關(guān)注點。通常采用AOP技術(shù)來對橫切關(guān)注點進行建模和實現(xiàn)。 1．Securtiy Aspect：用于對整個系統(tǒng)的Security提供支持。 2．ErrorHandling Aspect：整個系統(tǒng)采用一致的錯誤/異常處理方式。 3．Log Aspect：用于系統(tǒng)異常、日志記錄、業(yè)務操作記錄等。 四．規(guī)則 1．系統(tǒng)各層次及層內(nèi)部子層次之間都不得跨層調(diào)用。 2．Entity object 在各個層之間傳遞數(shù)據(jù)。 3．需要在UI層綁定到列表的數(shù)據(jù)采用基于關(guān)系的DataSet傳遞，除此之外，應該使用Entity object傳遞數(shù)據(jù)。 4．對于每一個數(shù)據(jù)庫表（Table）都有一個DB Entity class與之對應，針對每一個Entity class都會有一個BEM Class與之對應。 5．有些跨數(shù)據(jù)庫或跨表的操作（如復雜的聯(lián)合查詢）也需要由相應的BEM Class來提供支持。 6．對于相對簡單的系統(tǒng)，可以考慮將Business Function子層和Business Flow 子層合并為一個。 7．UI層和BL層禁止出現(xiàn)任何SQL語句。 五．錯誤與異常 異常可以分為系統(tǒng)異常（如網(wǎng)絡突然斷開）和業(yè)務異常（如用戶的輸入值超出最大范圍），業(yè)務異常必須被轉(zhuǎn)化為業(yè)務執(zhí)行的結(jié)果。 1．DataAccess層不得向上層隱藏任何異常（該層拋出的異常幾乎都是系統(tǒng)異常）。 2．要明確區(qū)分業(yè)務執(zhí)行的結(jié)果和系統(tǒng)異常。比如驗證用戶的合法性，如果對應的用戶ID不存在，不應該拋出異常，而是返回（或通過out參數(shù)）一個表示驗證 結(jié)果的枚舉值，這屬于業(yè)務執(zhí)行的結(jié)果。但是，如果在從數(shù)據(jù)庫中提取用戶信息時，數(shù)據(jù)庫連接突然斷開，則應該拋出系統(tǒng)異常。 3．在有些情況下，BL層應根據(jù)業(yè)務的需要捕獲某些系統(tǒng)異常，并將其轉(zhuǎn)化為業(yè)務執(zhí)行的結(jié)果。比如，某個業(yè)務要求試探指定的數(shù)據(jù)庫是否可連接，這時BL就需要將數(shù)據(jù)庫連接失敗的系統(tǒng)異常轉(zhuǎn)換為業(yè)務執(zhí)行的結(jié)果。 4．UI層(包括Service層)除了從調(diào)用BL層的API獲取的返回值來查看業(yè)務的執(zhí)行結(jié)果外，還需要截獲所有的系統(tǒng)異常，并將其解釋為友好的錯誤信息呈現(xiàn)給用戶。 六．項目組織目結(jié)構(gòu) 以BAS系統(tǒng)為例。 1．主目錄結(jié)構(gòu)：  2．命名空間命名：每個dll的根命名空間即是該dll的名字，如EAS.BL.dll的根命名空間就是EAS.BL。每個根命名空間下面可以根據(jù)需求的 分類而增加子命名空間，比如，EAS.BL的子空間EAS.BL.Order與EAS.BL.Permission分別處理不同的業(yè)務邏輯。 3.包含眾多子項目的龐大項目的物理組織：  核心子項目Core的位置：  Core子項目中包含一些公共的基礎設施，如錯誤處理、權(quán)限控制方面等。 七．發(fā)布服務與服務回調(diào) 以EAS系統(tǒng)為例。  1．同UI層的Page一樣，服務也不允許拋出任何異常，而是應該以返回錯誤碼(int型，1表示成功，其它值表示失敗)的形式來表明服務調(diào)用出現(xiàn)了錯誤，如果方法有返回值，則返回值以out參數(shù)提供。 2. 如果BAS系統(tǒng)提供了WebService（Remoting）服務，則BAS必須提供BAS.Entrance.dll。 BAS.Entrance.dll封裝了與BAS服務交換信息的通信機制，客戶系統(tǒng)只要通過BAS.Entrance.dll就可以非常簡便地訪問BAS 提供的服務。 3．如果BAS需要通過WebService（Remoting）回調(diào)客戶系統(tǒng)，則必須提供僅僅定義了接口的BAS.CallBack.dll，客戶系統(tǒng)將引用該dll，實現(xiàn)其中的接口，并將其發(fā)布為服務，供BAS回調(diào)。 4．當WebService的參數(shù)或返回值需要是復雜類型――即架構(gòu)圖中的Service Entity，則Service Entity應該在對應的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定義。 WebService定義的方法中的復雜類型應該使用Xml字符串代替（注意，Entrance和CallBack接口對應服務的方法的參數(shù)是強類型 的），而Xml字符串和復雜類型對象之間的轉(zhuǎn)換應當在BAS.Entrance.dll或BAS.CallBack.dll中實現(xiàn)。 |
|
|
