• 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做修改,然后将它传递到下一层.

分布模式