A Table Module organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model is that if you have many orders, a Domain Model will have one order object per order, while …
个人推荐 http://www.jdon.com 里面的文章！ 板桥里人(banq)是这个网站的掌门人，他对各种技术、模式的讲解非常易懂。
1. Distrubuted objectes are said to help balance performance, but in fact they usually do not。 Besides, they often make the system harder to build or deploy 2. Remote interfaces has to be different from local ones in order to reduce calls. If you choose a middleware to make them transprent, which means you’d use …
An object that acts as a Gateway to a single record in a data source 一个Domain Object对应一个Row Data Gateway 对象，这样可以将持久化逻辑从Domain Object中解耦出去
"Build an object model of the domain that incorporate both behavior and data"
大师l [13:00]: 标志文件有一般有2种功能，一种是表明此文件已传送完毕，一种是核对，即在文件内容写明传送文件的大小和条数 大师l [13:01]: 对于批处理来说，加上标志文件是必不可少的 菜鸟 [13:01]: 受教了 大师l [13:02]: 如果仅仅说明文件已传送完毕，可为空 大师l [13:06]: 标志文件肯定是需要的 菜鸟 [13:06]: 哦 大师l [13:07]: 如果他是轮询方式处理文件，你一传文件她就检测到文件，他就开始处理，可是你的文件还正在处理呢 大师l [13:08]: 如果文件是损坏的文件，他也不知道的
如果分了三层，当第三层的接口改了，只需要改第二层的调用代码，而不用改第一层的代码。如果不分层全都粘在一起，比如说展现逻辑和业务逻辑都调用了DAO接口，那么DAO接口变化时，业务逻辑代码和展现逻辑代码都要改了
Active Record 将数据持久化的逻辑(CRUD操作)直接写在Domain Object里面。“包装数据库表或视图中数据行的对象，封装数据库访问，在数据上添加域逻辑”
Presentation Tier Patterns: 1. Interceptiing Filter。 一种AOP思想的体现。将requet/response的“通用”的pre-处理和post-处理放到一个filter servlet中来。这样就只需写一个filter，而不必将通用代码在各个servlet中都写一份。关于“通用”代码，例子有会话验证、编码转换等 2.Front Controler。 一种Facade思想。将所有的请求都交给一个或几个Servlet集中处理。这个Servlet可以把按请求的具体内容再将它分发给真正的处理者。这样的好处是可以只写一份公用代码，对所有request应用通用逻辑，还可以限制WEB系统的access point。 典型的例子有Spring的DispatcherServlet 3.Context Object Controller 不去从与协议密切相关的容器中去拿东西（如request.getParameter()），而是从与协议无关的context中去拿。这样可以去掉应用对协议的依赖。 个人认为这个模式没多大意义，因为所有的WEB应用基本上都完全采用HTTP协议 4.Application Controller 将action管理和view管理集中化、模块化。 5.View Helper 将View与它的处理逻辑分开。它的处理逻辑包括 业务逻辑、控制逻辑、展现格式化逻辑等。典型的例子如 Controller，JSTL，自建标签 等 6.Composite View 在页面上，如果要使用复合视图时，要使布局和各页面的内容分离。如Tiles，Sitemesh 7.Service to Worker 在把控制权传给View之前处理好请求并执行业务逻辑 8.Dispatch View 如果业务逻辑很少，并且View自己可以处理请求并执行业务逻辑，则把控制权直接交给View 9.Business Delegate 在客户端/表现层 和 业务层之间再放一个Business Delegate，它代理业务层向客户端/表现层服务，并隐藏业务层的实现细节。主要好处有： a.消除业务层和客户端/表现层之间的耦合 b.把网络、技术方面的exception（如naming、socket）翻译成可读的exception c.Business Delegate可以做一些附加的动作，比如出错重试、验证、缓存、同步等，而且这些细节客户端/表现层都不需要知道 d.查找远端对象并与之交互的职责交给了Business Delegate，表现层/客户端不需要关心这些事情 10.Service Locator 使用一个接口，集中地、透明地定位远端的服务组件。 11.Session Facade 在业务层，向远端的Client只暴露一个集中的服务接口。这样可以向Client隐藏服务层的细节，并可以集中地进行事务管理和安全管理。我不太认可这种方式，因为客户要求的服务是非常多的，这会使得此Facade中也存在很多并且相关性不是很强的方法，不符强内聚的原则 …
啥叫“可移植性”？可移植性就是当消费者对供应商的服务不太满意时，可以换用另一个供应商，并且不需要调整自己接受服务的方式。典型的例子有：JAVA程序 V.S 操作系统，应用程序 V.S. 数据库 观察这些例子，可以发现实现可移植性的关键是：存在着一个中间层适配器，将供应商的接口适配为消费者想要的服务。供应商变了，适配器也要换。把java程序从windows迁移到linux，就需要换用linux下的jvm；把数据库从sql server换成oracle，就需把jdbc驱动换成oracle的驱动；而对应用程序开发人员来说，常常需要考虑的是，当服务组件从EJB换成Web Services时，应用层的代码要怎么改？ 解决办法和上面一样，在一开始设计的时候就要在应用层和服务层之间设计一个适配器接口以适配服务组件的接口，当服务组件更换时，重新写一个类实现这个适配器接口就可以了，应用层代码本身不需要改动。 实现可移植性还有一个约束：消费者所需的服务必须是独立于任何供应商特性的。如果在应用层的数据库查询代码里用了“select top 10 ….from …”，那么这个系统就只能用在sql server上了