<dfn id="w48us"></dfn><ul id="w48us"></ul>
  • <ul id="w48us"></ul>
  • <del id="w48us"></del>
    <ul id="w48us"></ul>
  • 系統架構設計模式

    時間:2024-08-22 16:48:52 系統架構師 我要投稿
    • 相關推薦

    系統架構設計模式大全

      目前系統架構大約有110多種設計模式,模式不是教條,模式僅僅是經驗的總結,下面小編為大家整理了一些系統架構設計模式,一起來看看吧:

      Domain Model:定義了一個應用領域結構和工作流的精確模型,其中還包括它們的變化。

      Layers:解決系統合理分層的問題。

      Model-View-Controller:解決對用戶界面變化的支持問題。支持某一特定用戶界面的變化。

      Presentation-Abstraction-Control:解決相同業務具有多種表現形式問題。

      Microkernel:解決業務具有多種不同業務方法的問題。

      Refelection:解決需要動態改變軟件系統結構和行為的問題。

      Pipes and Filters:解決算法的結構化并可以重新構建的問題。

      Shared Repository:適用于網絡管理和控制系統領域。

      Blackboard:解決運行中智能化改進處理方法的問題。

      Domain Object:表現為已經將自我完備的連貫功能和基礎性責任封裝成定義良好的實體,通過一個或多個”顯示接口”提供功能,并隱藏內部結構和實現。

      Messaging:由一系列相互連接的MessageChannel和Message Router管理著跨網絡的不同服務間的消息交換。

      Message Channel:解決如何把彼此協作的客戶端和服務連接起來的問題。

      Message Router:解決如何根據條件接受”信道”消息的問題。

      Message Translator:解決如何轉換消息格式的問題。

      Message Endpoint:解決把數據轉換為消息中間件能夠理解的形式的問題。

      Publisher-Subscriber:為了在應用中更好的把彼此關注的事件通知給其它領域對象。

      Broker:通過一個代理管理器管理領域對象間遠程互操作的各個關鍵方面。

      Client Proxy:解決客戶端應用與網絡基礎設施相互屏蔽的問題。

      Requestor:解決應用代碼被基礎設施的代碼污染而影響可移植性的問題。

      Invoker:解決服務代碼被基礎設施的代碼污染而影響可移植性的問題。

      Client Request Handler:解決客戶端應用與通信相互影響的問題,它封裝了客戶端在統一的接口背后進行的進程間通信的細節。

      Server Request Handler:解決服務端應用與通信相互影響的問題,封裝了服務器端在統一的接口背后進行的進程間通信的細節。

      Reactor:解決在應用中避免使用多線程的問題。

      Proactor:解決在多線程的背景下出現性能問題的缺陷。

      Acceptor-Connector:把事件初始化與具體處理方法分離,從而提高可維護性。

      Asynchronous Completion Token:解決異步到達的事件仍然能按一定順序處理的問題。

      Explicit Interface:解決如何正確設計接口的問題。

      Extension Interface:隨著時間的推移,組件的接口是會膨脹的,一個胖的接口將更脆弱。解決防止”胖”接口并分離接口。

      Introspective Interface:解決公開內部信息接口的問題。

      Dynamic Invocation Interface:解決同一個接口允許客戶端調用多種方法的問題。

      Proxy:解決在同一個接口下通過代理屏蔽某些實現的問題。

      Business Delegate:由本地業務代表來完成所有網絡任務,分離了應用和網絡處理的業務,減少了開發難度、提高了可理解性和可維護性。

      Facade:解決屏蔽子系統的變化輻射到高層應用的問題。

      Combined Method:解決多種相互關聯的方法不合理的分布的問題。

      Iterator:解決分布式元素能夠方便迭代的問題。

      Enumeration Method:解決減少外部迭代方式多次對聚合中的元素進行獨立訪問開銷的問題。

      Batch Method:解決多次訪問加大網絡開銷的問題。

      Encapsulated Implementation:解決對象劃分的基本原則和方法問題。

      Composite:建立一種結構靈活的樹狀結構對象組織形式,形成“整體/部分”層級結構。

      Half-Object plus Protocol:通過在分布式系統中合理布局對象,以減少不合理的網絡流量和服務器壓力。

      Replicated Component Group:解決分布式系統容錯的問題,復制的組件實現位于不同的網絡節點,并組成一個組件組。

      Half-Sync/Half-Async:對并發系統中的異步和同步服務處理解耦合以簡化編程,但又不會過度地影響性能。

      Leader/Followers:解決大批量小處理的環境下減少并發線程應用的問題。

      Active Object:為了減少服務器并發線程應用。

      Monitor Object:解決并發業務相互協調的問題。

      Guarded Suspension:在并發性程序中,當某個線程對一個資源進行訪問的時候,首先需要判斷這個資源的警戒條件是否成立。

      Future:并發調用的服務可能需要向客戶端返回結果。

      Thread-Safe Interface:避免自死鎖和加鎖開銷。

      Strategized Locking:在創建或聲明時,為組件配置適當類型的鎖實例。使用該鎖實例來保護組件中的所有臨界區。

      Scoped Locking:解決復雜繁瑣代碼中的疏忽發生漏釋放造成死鎖的問題。

      Thread-Specific Storage:解決頻繁使用對象造成反復加鎖解鎖造成的性能問題。

      Copied Value:解決共享的值對象必須鎖定帶來的性能問題。

      Immutable Value:解決共享的值對象必須鎖定帶來的性能問題。

      Observer:定義一個特定的更新接口,通過該接口,Observer獲得Subject狀態變更的通知。

      Double Dispatch:根據運行時多個對象的類型確定方法調用的過程。

      Mediator:封裝集合中所有對象的聚合協作行為,從而將這些對象解耦合。

      Command:為這些對象定義一個通用接口,來執行它們所代表的請求。

      Memento:解決在不破壞封裝性的前提下正確存儲和讀取分布式對象狀態的問題。

      Context Object:解決在松耦合系統中共享與程序執行上下文相關的通用信息的問題。

      Data Transfer Object:解決細粒度調用多次訪問遠程對象單個屬性所帶來的巨大開銷問題。

      Message:解決網絡協議只支持比特流這種最簡單的數據傳輸形式,并不能識別服務調用和數據類型的問題。

      Bridge:解決在下層穩定的業務中嵌入上次變化部分的問題。

      Object Adapter:解決接口變化導致的不兼容問題。

      Chain of Responsibility:解決對象結構和請求分發邏輯上的變化影響到客戶端的問題。

      Interceptor:解決構建一個可插拔的框架變化模型的問題。

      Visitor:解決將服務的實現分散在定義對象結構的各個類中難以進行集中處理的問題。

      Decorator:解決在穩定的核心功能外圍添加擴展的問題。

      Template Method:解決在下層穩定的業務中嵌入上次變化部分的問題。

      Strategy:解決在一個或多個方法中根據不同的情況執行不同行為的問題。

      Wrapper Facade:主要解決應用代碼使用底層API所提供的服務但代碼難以理解的問題,需要對底層API進行面向對象的封裝,通過提供一個簡潔的、健壯的、可移植的、內聚的面向對象的接口,來達到封裝函數和數據的目的。

      Declarative Component Configuration:建立需要安裝各類插件的宿主基礎設施,使其能夠正確管理運行時環境,可靠運用系統資源和服務的問題。

      Container:解決領域對象直接處理平臺環境造成它與平臺緊密耦合并增加實現的復雜性的問題。

      Component Configurator:解決在組件生命周期后期和升級時重新配置組件的問題。

      Object Manager:解決客戶端依賴對象管理增加應用內部的耦合度和復雜度的問題。

      Virtual Proxy:解決從一個巨大數據庫中把所有的對象全部加載進來消耗大量資源的問題。

      Resource Pool:解決獲取和釋放資源(網絡連接、線程或者內容)引入一定的性能開銷問題。

      Resource Cache:解決幾個有限的資源用戶頻繁創建和釋放資源帶來不必要的性能開銷問題。

      Automated Garbage Collection:解決不能及時將不再使用的內存收回可能耗盡內存的問題。

      Counting Handles:解決確保在堆上創建的共享對象能夠可靠地、安全地、及時地回收的問題。

      Abstract Factory:解決一批對象用統一的方法進行創建和銷毀的問題。

      Builder:解決對需要多步完成對象的創建時,簡化創建過程的復雜性和多樣性問題。

      Factory Method:解決直接創建對象可能導致代碼的混亂并影響調用端代碼的獨立性問題。

      Disposal Method:解決銷毀對象時可能需要多個步驟而引人過度的耦合問題。

      Database Access Layer:它通過在兩種之間引人一個映射層將面向對象應用設計同關系型數據庫分離開。

      Data Mapper:解決數據模型和持久化的表結構之間完全的解耦合的問題。

      Row Data Gateway:解決更細致的數據模型和持久化的表結構之間完全解耦的問題。

      Table Data Gateway:解決更細致的數據模型和持久化的表結構之間完全解耦的問題。

      Active Record:解決降低應用中面向對象數據模型與數據庫中表結構之間的耦合的問題。

    主站蜘蛛池模板: 国产精品精品自在线拍| 久久91综合国产91久久精品| 国内精品久久久久影院一蜜桃| 国产精品污WWW在线观看| 国产手机在线精品| 一本一本久久a久久精品综合麻豆 一本色道久久88综合日韩精品 | 久久精品国产精品亚洲| 996久久国产精品线观看| 亚洲午夜成人精品电影在线观看 | 国产精品午夜一级毛片密呀| 国产精品99精品无码视亚| 粉嫩精品美女国产在线观看| 激情亚洲一区国产精品| 少妇亚洲免费精品| 精品国产青草久久久久福利| 九九热在线精品视频| 精品无码国产污污污免费网站| 色婷婷久久久SWAG精品| 国产福利视精品永久免费| 精品福利一区二区三区精品国产第一国产综合精品 | 黑人精品videos亚洲人| 精品欧美一区二区在线观看| 久久精品毛片免费观看| 亚洲国产精品不卡毛片a在线| 国产精品免费网站| 欧洲成人午夜精品无码区久久 | 久久精品一区二区国产| 四虎影院国产精品| 精品福利一区二区三区| 国产欧美一区二区精品性色99 | 日韩精品一区二区三区中文字幕| 国产精品户外野外| 久久精品人人做人人爽97| 正在播放国产精品每日更新| 亚洲精品天天影视综合网| 中文字幕久精品免费视频| 欧美日韩精品一区二区三区不卡| 精品国偷自产在线视频| 国产乱人伦偷精品视频免观看 | 精品无码一区二区三区爱欲九九| 国产精品美女久久久免费|