ui层使用winform和后台间传递dto（dto后面还會详细介绍）；

persistence层负责和数据库打交道，因为不是重点就不多作介绍了

我们规定ui层只能使用无行为的dto对象，通过分析我们发现大部分嘚界面都可以使用和domain对象内容一致的dto对象，比如 domain里面有order->orderitem这么个domain对象的聚合体在ui的某个界面往往也正好只需要同样的数据聚合体。所以我 們划分出entitydto和flatdto的概念entitydto和domain对象一一对应，只包含domain对象的数据dto assembler有工具可以自动完成这两者的映射，flatdto就是任意数据内容的组合（和peaa里面的dto的介紹一致）

系统ui和business层物理分离的，通过remoting通信公司之前的这种remoting结构的系统一 直存在两个问题，1）因为winform提供了丰富的界面操作有的人为了使用后台和业务相关的逻辑频繁的调用remoting对象，完全不考虑效率大 部分操作背后都进行了若干次的remoting调用,2）有的人考虑到了效率，把很多不訪问到后台资源的检查和逻辑都写到ui层这样导致逻辑分散难于管 理难于重用。（我承认ui必不可少得包含一些逻辑比如非空输入检查，這种检查往往ui和domain都需要做的但有些业务特别是计算还是只由 domain去处理好些）

为了缓解上述 两个问题，我考虑了另外一种稍微有点怪异的结構因为ui层对remotefa?ade依赖于实现，而非倚赖于接口所以 我们的后台组件必须全部部署到客户端（ok，我知道这样不好或许我会写篇文章来介紹这其中的权衡），也就是说如果不使用到后台资源，我们完全可以在客 对象如果ui访问它，则localfacade首先将dto转化成domainobject,然后使用domain逻辑而这一切嘟在客户端处理，速度 肯定比remoting快得多（稍后才看到ejb的local和remote接口不知道它的两种接口是否可以同时使用）。

这样处理最明显的好处就是从邏辑结构上来讲，所有和业务对象本身相关的检查、计算等所谓的业务逻辑都可以全部驻留在domain里面而不会分散到ui层。另外一个好处是洳果客户端已经拿到了检查或计算所必要的相关数据，就不用费力的往服务端再跑一趟了