• Remote Facade遠程外觀
  • ?
  • 在OO模型中,存在很多規模小,且有小方法的對象.這些小對象會導致很多的對象間交互.
  • 在單一地址空間里,小對象沒問題.
  • 但是,當在兩個進程間做調用時,頻繁的跨進程交互會造成性能開銷.
  • 遠程外觀,減少遠程調用的次數.
    • 建立在大量的細粒度對象之上,提供一個粗粒度的外觀.
    • 不包括任何的領域邏輯.只是將方法轉換到細粒度對象上.
  • 運行機制
    • 細粒度對象適合于解釋復雜的邏輯.
    • 遠程外觀使用bluck accessor來使用一個getter/setter來完成在細粒度對象中的所有gettter/setter.
    • 單個遠程外觀,也可以作為多個細粒度對象的一個遠程入口.
    • 遠程外觀的設計基于特定的客戶需求.
      • 外觀的設計是為了簡化外觀用戶的使用,而不是為了簡化內部系統.
      • 所以,遠程對象中的大量不同方法實際上都在底層對象上調用了相同的方法.
    • 狀態
      • 無狀態.可以組成池,來提高資源的利用率和效率.
      • 有狀態.當訪問的客戶很多時,可能會出現效率問題.
  • 使用時機
    • 需要遠程訪問細粒度對象模型時.
    • 最常用在表現和領域模型之間.通常它們處于不同的進程中.
    • 如果所有的交互都在單一的進程中,那么不需要這樣的轉變.
• Data Transfer Object
  • 一個為了減少方法調用次數而在進程間傳輸數據的對象.
    • 當使用遠程接口時,如果正在使用遠程外觀,每一次調用的代價會很大.
    • 需要減少調用的次數,就意味著每次調用都需要傳遞大量數據.
    • 解決的辦法是使用數據傳輸對象.該對象將保留調用所用到的數據.
    • 它需要被序列化以便能在鏈接中傳輸.
  • 運行機制
    • DTO一般只是一堆域和getter/setter.
      • 價值在于允許一次調用中傳輸幾部分信息.該特性是分布式的本質.
      • 一般會包含多個服務器對象,根據遠端對象的需要.
      • 常見形式是記錄集,或者集合數據結構.
    • 當遠端對象需要某些數據時,它將詢問一個合適的DTO
      • 通常,DTO會包含遠多于遠端對象所需要的數據量.
      • 這是因為遠程調用的開銷.寧可一次調用多傳輸以備以后使用.
    • 不想在Client端看到領域對象類.
      • 這樣就等于在Client端拷貝整個領域模型.
      • 所以,應該從領域對象中傳遞一些簡單格式的數據.
    • DTO中的域都是簡單的原生類型,或者是其它的DTO.
      • DTO之間的結構應該只是簡單的分層結構.
      • 目的是更簡單的進行序列化.
      • 并且使傳輸的雙方更容易理解.DTO必須被傳輸的雙方知道.
    • DTO是圍繞特定的Client端而設計的.
      • WEB和GUI會關聯不同的DTO.
    • DTO的數目
      • 使用單一的DTO來處理整個交互.減少編碼量，難以理解傳輸數據．
      • 用不同的DTO來處理不同的請求.清晰,但是會產生大量的ＤＴＯ．
    • 請求雙方
      • 請求方和發送方各自一個DTO,還是公用一個ＤＴＯ．
    • 可變／恒定的DTO
      • 恒定的ＤＴＯ,從Client端收到一個DTO后,新創建并回傳一個不同的DTO.
      • 可變的,直接修改請求的DTO.逐步放入數據的方式.
    • 組裝器
      • 獨立了領域對象和DTO.使兩者不相互依賴.
      • 映射器模式的實例:組裝器
        • 負責從領域模型組裝一個DTO.或者依據DTO更新領域模型.
      • 同時可以有多個組裝器對象共享一個DTO.
        • 相同的數據在不同場景下有不同的更新語義.
  • 使用時機
    • 在一個方法調用中,在兩個進程之間傳輸多個數據項,應使用它.
    • DTO可以作為不同軟件層次間通用的數據源.
      • 每個層次對DTO做修改,然后將它傳遞到下一層.

?

轉載于:https://www.cnblogs.com/robyn/p/3527038.html

總結

以上是生活随笔為你收集整理的分布模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。