《J2EE核心模式》的原文摘录
-
那些深刻的、 真正有用的模式大多都是很古老的东西， 见到这么一个模式的时候， 你往往会说： "嘿， 我从前就这么做过。”但是， 只有当专家为这个模式命名之后， 你才获得了一整套讨论这个问题的语汇；此前， 由于缺乏这种语汇， 你往往想不到怎样使用这个模式， 因此命名有助于我们更好地应用模式 (查看原文)
-
简而言之， 没有哪个模式是一个孤立的个体。 每个模式都只有靠与其他模式相互支持才得以存在于世界之中：每个模式都嵌入到更大的模式里， 被同样大小的模式环绕， 并且还有更小的模式嵌入在它的内部——这也就是所谓＂相互支持＂的意思。
——Christopher Alexander (查看原文)
-
创建一个通用的接口类型， 使其具有和 “特定于框架的数据结构” 相同的接口方法。然后， 只要把新建的接口类型覆盖到特定于框架的对象上， 就可以将这个对象以新建接口的类型传递给业务层。 这样， 无须手工复制信息， 业务层也不会与框架发生耦合。 (查看原文)
-
有些设计者把 “ 用session bean包装entity bean” 解读为 “ 每个entity bean都必须由属于它自己的session bean来保护＂ ， 这是一种误读， 因为这会导致session bean沦落为entity bean的代理， 而不是它本应成为的门面 (查看原文)
-
这种策略是基于基本过滤器策略的， 基本过滤器作为一个基类， 封装了过滤器API的所有细节（见本章前面的基本过滤器策略）。 模板过滤器策略使用这个积累提供了模板方法[GoF]的功能。
这样定义了TemplateFilter类之后，每个作为子类的过滤器只需要doPreProcessing和 doPostProcessing方法。 但是子类也可以实现全部3个方法
模板过滤器规定了每个过滤器的控制流程，这样过滤器开发者就可以专注于预处理／后处理逻辑的语义了。最后，因为模板过滤器是一个基本过滤器，它也封装了所有过滤器都要用到的代玛 (查看原文)
-
与物理资源映射相比，我们通常推荐逻辑资源映射策略， 因为后者能够提供更高的灵活性 (查看原文)
-
视图助手把业务逻辑和处理逻辑从视图中分解出来， 放到了助手对象中， 因此为控制和分派提供了一个集中处理点。 流程控制逻辑放进了控制器中， 与视图格式相关的代码则放进了助手对象 (查看原文)
