表现层设计考虑
会话管理 在客户端保存会话状态 优点：
①实现容易
②保存状态比较少时，效果好
③需要多台Server实现负载均衡时，无需在Server间复制会话状态。
实现策略：
①HTML隐藏字段
②HTTP Cookie
③直接放进URL里
1. HTML隐藏字段的缺点：
①需保存状态较多时，缺点尤其明显：系统性能下降；状态在请求和响应中都要通过网络往复传输。
②保存的状态只能是字符串形式的值，任何对象引用必须“字符串化”；加密处理。
2. HTTP Cookie的缺点：
①同上
②同上；对于Cookie header的大小有限制，也就限制了能够保存的数据量。
安全问题
在表现层保存会话状态 session ID
优点：
①状态保存在Server，不会受到数据量大小或是数据类型方面的限制。
②会话状态不会在每个请求中都通过网络传输一次，系统性能不会受到影响。
③在Server保存会话状态，可以按照需要和代价，在繁、简间灵活选择，兼顾可扩展性和性能。
缺点：
需要在集群的多个Server间复制会话状态。
在业务层或资源层保存会话状态 || ||
EJB组件 关系型数据库
控制客户端访问 保护视图 策略：
①加入一种应用逻辑
②配置运行时系统
常见方法：
①采用一个控制器
②在视图中直接加入保护
1.
在视图内部中实现保护 a.
阻塞对整个资源的访问 b.
只阻塞对局部资源的访问 2.
每页加入“要么全部 - 要么没有”的保护 3.
加入对页面局部的保护 a.
根据用户角色不显示视图的局部内容 b.
根据系统状态或错误条件不显示视图的局部内容 通过配置实现保护 web.xml
1.
通过标准安全限制实现资源保护 2.
通过一个简单、通用的配置实现资源保护 只需把那些限制访问的资源放到Web应用的/WEB-INF/目录下即可。
重复的表单提交 同步器令牌（又名“时曾相识”令牌）
验证 客户端+服务器端验证
在客户端验证 JavaScript
在服务器端验证 1.
基于表单的验证 容易实现，比较高效；应用系统越大，造成的重复代码越多。
2.
基于抽象类型的验证 从状态中抽象出类型和限制信息，放入一个通用的框架中。
例如，可以使用一个组件或者一个子系统来封装验证逻辑。
缺陷：
①效率、性能上可能具有潜在的损失；
②通用解决方案强大，但难于理解、不易维护。
助手类属性——完整性和一致性 JavaBean助手类通常用于存放由客户端请求传来的中间状态。
<jsp:setProperty name="helper" property="*"/>
当请求中的参数值为空的时候，技术规范规定，不对该属性的值做任何变化。
解决方案：
在多次请求之间重置JavaBean的所有状态。
表现层不佳实践多个视图中都包括控制代码 参照解决方案：
合并控制代码，引入一个控制器和相关的命令助手。
Ch4，“引入控制器”、“隔离不同逻辑” Ch6，“命令与控制器策略”、“视图助手”把表现层的数据结构暴露给业务层 表现层的数据结构，例如
HttpServletRequest，应该只限于表现层。
参照解决方案：
Ch4，“对业务层隐藏表现细节”把表现层数据结构暴露给业务领域对象 参照解决方案：
同上允许重复提交表单 参照解决方案：
需要监管、控制请求流程。
Ch4，“引入同步器令牌”把敏感资源暴露给客户端的直接访问 参照解决方案：
保护敏感资源、禁止客户端直接访问。
Ch4，“对客户端隐藏资源”假定<jsp:setProperty>会重置Bean属性 参照解决方案：
记住<jsp:setProperty>的这种不太直观的赋值机制，在使用bean属性之前先做初始赋值。
创建出“胖控制器” 参照解决方案：
Ch4，“引入控制器”，Ch6，“命令与控制器策略”； Ch4，“隔离不同逻辑”，Ch6，“视图助手”把视图助手当作Scriptlet使用 参照解决方案：
视图中的Java Scriptlet；使用JSTL助手；使用标记库；标记文件助手