詳解三層架構圖

標籤：style   blog   http   java   使用   width   

 PS： 在看三層架構的時候，找的了一個我感覺不錯的材料，裡面有如下一張圖，打算詳細的解釋一下這張圖，也總結一下三層的知識

  

一、系統各層次職責

     1.UI（User Interface）層的職責是資料的展現和採集，資料擷取的結果通常以Entity object提交給BL層處理Service Interface側層用於將業務或資料資源發布為服務（如WebServices）。

    2.BL（Business Logic）層的職責是按預定的商務邏輯處理UI層提交的請求。

    （1）Business Function 子層負責基本業務功能的實現。

    （2）Business Flow 子層負責將Business Function子層提供的多個基本業務功能組織成一個完整的業務流（Transaction只能在Business Flow 子層開啟。）

    3．ResourceAccess層的職責是提供全面的資源訪問功能支援，並向上層屏蔽資源的來源。

  （1）BEM（Business Entity Manager）子層採用DataAccess子層和ServiceAccess子層來提供業務需要的基礎資料/資源訪問能力。

  （2）DataAccess子層負責從資料庫中存取資源，並向BEM子層屏蔽所有的SQL語句以及資料庫類型差異。

    DB Adapter子層負責屏蔽資料庫類型的差異。

    ORM子層負責提供對象－關係映射的功能。

    Relation子層提供ORM無法完成的基於關係（Relation）的資料訪問功能。

  （3）ServiceAccess子層用於以SOA的方式從外部系統擷取資源。

         註：Service Entrance用於簡化對Service的訪問，它相當於Service的代理，客戶直接使用Service Entrance就可以訪問系統發布的服務。Service      Entrance為特定的平台（如Java、.Net）提供強型別的介面，內部可能隱藏了複雜的參數類型轉換。

  （4）ConfigAccess子層用於從設定檔中擷取配置object或將配置object儲存倒設定檔。

    4．Entity側層跨越UI/BEM/ResourceManager層，在這些層之間傳遞資料。Entity側層中包含三類Entity，如所示：

  

二、Aspect

    Aspect貫穿於系統各層，是系統的橫切關注點。通常採用AOP技術來對橫切關注點進行建模和實現。

    1．Securtiy Aspect：用於對整個系統的Security提供支援。

    2．ErrorHandling Aspect：整個系統採用一致的錯誤/異常處理方式。

    3．Log Aspect：用於系統異常、日誌記錄、業務操作記錄等。

 

三、規則

    1．系統各層次及層內部子層次之間都不得跨層調用。

    2．Entity object 在各個層之間傳遞資料。

    3．需要在UI層綁定到列表的資料採用基於關係的DataSet傳遞，除此之外，應該使用Entity object傳遞資料。

    4．對於每一個資料庫表（Table）都有一個DB Entity class與之對應，針對每一個Entity class都會有一個BEM Class與之對應。

    5．有些跨資料庫或跨表的操作（如複雜的聯集查詢）也需要由相應的BEM Class來提供支援。

    6．對於相對簡單的系統，可以考慮將Business Function子層和Business Flow 子層合并為一個。

    7．UI層和BL層禁止出現任何SQL語句。

 

四、錯誤與異常

         異常可以分為系統異常（如網路突然斷開）和業務異常（如使用者的輸入值超出最大範圍），業務異常必須被轉化為業務執行的結果。

    1．DataAccess層不得向上層隱藏任何異常（該層拋出的異常幾乎都是系統異常）。

    2．要明確區分業務執行的結果和系統異常。比如驗證使用者的合法性，如果對應的使用者ID不存在，不應該拋出異常，而是返回（或通過out參數）一個表示驗證 結果的枚舉值，這屬於業務執行的結果。但是，如果在從資料庫中提取使用者資訊時，資料庫連接突然斷開，則應該拋出系統異常。

    3．在有些情況下，BL層應根據業務的需要捕獲某些系統異常，並將其轉化為業務執行的結果。比如，某個業務要求試探指定的資料庫是否可串連，這時BL就需要將資料庫連接失敗的系統異常轉換為業務執行的結果。

    4．UI層(包括Service層)除了從調用BL層的API擷取的返回值來查看業務的執行結果外，還需要截獲所有的系統異常，並將其解釋為友好的錯誤資訊呈現給使用者。

 

五、項目組織目結構

    以BAS系統為例。

     1．主目錄結構：

 

     2．命名空間命名：每個dll的根命名空間即是該dll的名字，如EAS.BL.dll的根命名空間就是EAS.BL。每個根命名空間下面可以根據需求的 分類而增加子命名空間，比如，EAS.BL的子空間EAS.BL.Order與EAS.BL.Permission分別處理不同的商務邏輯。

    3.包含眾多子項目的龐大項目的物理組織：

 

核心子項目Core的位置：

 

 

Core子項目中包含一些公用的基礎設施，如錯誤處理、許可權控制方面等。

六、發布服務與服務回調

以EAS系統為例。

 

     1．同UI層的Page一樣，服務也不允許拋出任何異常，而是應該以返回錯誤碼(int型，1表示成功，其它值表示失敗)的形式來表明服務調用出現了錯誤，如果方法有返回值，則返回值以out參數提供。

     2.如果BAS系統提供了WebService（Remoting）服務，則BAS必須提供BAS.Entrance.dll。 BAS.Entrance.dll封裝了與BAS服務交換資訊的通訊機制，客戶系統只要通過BAS.Entrance.dll就可以非常簡便地訪問BAS 提供的服務。

     3．如果BAS需要通過WebService（Remoting）回調客戶系統，則必須提供僅僅定義了介面的BAS.CallBack.dll，客戶系統將引用該dll，實現其中的介面，並將其發布為服務，供BAS回調。

     4．當WebService的參數或返回值需要是複雜類型――即架構圖中的Service Entity，則Service Entity應該在對應的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定義。 WebService定義的方法中的複雜類型應該使用Xml字串代替（注意，Entrance和CallBack介面對應服務的方法的參數是強型別 的），而Xml字串和複雜類型對象之間的轉換應當在BAS.Entrance.dll或BAS.CallBack.dll中實現。