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