【筆記】軟件結構模式-分層結構

分層模式 

適用條件:
        應用可被分解爲多個子任務組
        每個子任務組處於特定抽象層次上
        接口應該是穩定的,甚至可以有標準協議來限定
設計要點:
        合理分層:
                定義合適的抽象層數
                層J 提供由層J+1使用的服務,同時委派任務給層J-1 。
                較多的服務放在高層往往比低層好,避免開發人員面對只有細微差別的原語
                通常高層關心相鄰的低層,但低層並不關心用戶的身份
                層間彼此要嚴格分離,注意避免層間的共享模塊導致放鬆嚴格分離原則

        層間通信:
                Push Mode:層J使用層J-1的服務時,任何要求的信息可以作爲服務調用的一部分來傳遞
                Pull Mode:低層自行從高層獲得信息,可以考慮使用publisher-subscriber 模式,缺點是導致低層對高層的依賴。

        回調函數:

                對自底向上通信,可以使用回調函數而避免破壞自頂向下的單路耦合。這裏高層要註冊低層的回調函數,當低層可能發往高層的事件集固定時,這種設計特別有效。Reactor模式給出了回調使用與事件分路傳輸相結合的一種面向對象實現方式。 Command模式給出瞭如何把回調函數封裝成第一類對象。


        錯誤處理:
                錯誤儘量在它出現的層內處理,以防止高層被許多不同錯誤和大量錯誤處理代碼陷入困境
                向更高層通知錯誤時,應試着把相似錯誤類型歸併成更一般的錯誤類型,避免高層面對贏了高層不能理解的低層錯誤。

反模式:
        污水池:如果我們的請求經過分層而沒有做任何事,這就是污水池反模式的徵兆
        巨石應用(Monolith):將分層應用打包成巨石,可能導致擴展困難

優缺點:
        結構清晰:分層隔離有利於降低整個應用程序的複雜度
        可測試性:使用Mocking和Faking,每一層可以獨立測試
        靈活性:接口定義良好的層很容易被語義上等價的實現替換掉。用橋接模式支持一個層提供的服務的多重實現, 策略模式用於一個層使用的算法動態替換, 用適配器讓不同接口的實現替換一個層的服務


        性能問題:因爲請求需要經過多個分層,可能會存在性能問題

        可伸縮性差:耦合太緊,很難對分層應用程序進行伸縮
        不必要的工作:低層執行的某些任務可能是高層不需要的或者重複的。
        難以認可層的正確粒度  層粒度的確定和層任務的分配是比較困難的
        

應用實例
        三層B/S結構(表現層-領域層-數據源層)
        OSI七層網絡模型

變體: 
        鬆散分層系統:每一層可以使用比它低的所有層的服務。提高靈活性的同時降低了可維護性。
        通過繼承分層:優點是高層可以根據需要修改子類服務。缺點是繼承關係造成高層與低層的緊耦合。 




發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章