第1章：导论。

模式能够：

利用一个经过验证可行的解决方案；

提供一套通用词汇；

约束解决方案的空间。

?

第2章：表现层设计考虑和不佳实践。

客户端验证：基于表单的验证、基于抽象类型的验证。

曾经在JSP中滥用过的助手类，通过助手类在页面和业务逻辑之间传递数据，有点类似于如今Struts中的Action作为传值模型时的情况。

表现层不佳实践：

多个视图中都包含控制代码；

表现层数据结构暴露给业务层或者业务领域对象，比如：暴露HTTPServletRequest；

重复提交表单；

敏感资源暴露给客户端直接访问，有个原则，敏感的东西不能放在WEB-INF之外；

胖控制器；

……

怎么区分后台视图层和前台页面层？或者说，怎么划分哪些事情JSP或者模板做，哪些事情JavaScript做？首先，根据模型驱动的原则，通常送到JSP或者模板上的都是通用模型的对象或者对象集，JSP或者模板根据需要选择展示出来，但是后续可抽取为不需和服务端交互状态下响应用户的行为，应当划分为JavaScript的工作。

?

第3章：业务层设计考虑和不佳实践：

session bean：根据EJB规范，每个session bean专门服务于一个客户端或者用户，生命时间等于客户端会话时间；在服务器崩溃后无法存活、无法持久化、会超时、可以涉及事务；支持构造有状态或无状态的对话模型。

不过现在的容器会话大多可以持久化了，会话复制和会话持久化应当是会话管理中重要的两个分支，通常情况下会话不需考虑完整的事务性，保证线程独立性即可。

至于无状态的session bean，可以被池化，以高效利用（EJB容器管理）。

entity bean：实体bean是否应该包含业务逻辑？按照下面三个原则去判定，还是比较清晰的：

这样的业务逻辑是否会引入实体之间的关系？比如处理UserInfo的时候，是否引入了AccountInfo，这样应当考虑根据模型驱动的原则，放置到专门的User或者Account相关的业务无状态bean中去；

是否要负责管理用户交互的工作流？

是否会担负起本该属于其他业务组件的责任？

有一个“是”，就说明不该包含这段业务逻辑。

尤其提一句，如果使用远程实体bean，就更应该减少实体bean之间的依赖关系，以提高性能和可用性。

业务层和集成层不佳实践：