设计表现层时需要考虑的几个问题
开发者在设计表现层时，可以使用不同的模型，这时需要考虑一些相关的设计问题。这些问题和模型关系的紧密程度也各有不同，它们可以影响系统的各个方面，包括有安全、数据完整性、可治理性和扩展性。虽然这些设计问题大部分都可以用模型的形式表示，但我们不打算这样做，因为这样更为抽象，我们选择以非正式的文档形式表示。我们只是根据不同的模型，将每个需要考虑的问题列出来。
Session治理
用户Session指的是跨越一个客户和服务器多个请求间的一个对话。我们将在以下部分根据用户Session的概念讨论这个问题。
客户端的Session状态
在客户端保存Session的状态指的是将Session的状态串行化并且嵌入到返回给客户的Html页面中。
在客户端保存Session的状态有这以下的好处：
. 它实现起来相对轻易
. 在保存少量的状态信息时，它工作得很好
此外，这个策略还消除了跨越多个服务器复制状态的问题，例如多个服务器间实现负载均衡时就会碰到这种情况。
在客户端保存Session状态通常有两个方法--HTML的隐藏字段和HTTP cookies--我们将在下面讨论这些策略。第三个策略则是在每个页面的URL中嵌入Session状态信息，例如<form action=someServlet?var1=x&var2=y method=GET＞。虽然第三个方法比较少见，但它也有着其它两个方法的许多限制。
HTML的隐藏字段（HTML Hidden Fields）
虽然这个方法实现起来相对轻易，不过使用HTML隐藏字段在客户端保存Session状态仍然有着许多的缺点。这些缺点在保存大量的状态时尤为突出。保存大量的状态将会对性能有很大的影响。因为每次发出请求和响应时，都需要在网络中传送这些状态信息。
此外，当你利用隐藏的字段来保存Session状态时，这些持久的状态值只能是字符串值，因此所有的对象引用都必须被“字符串化”，而这些信息除非经过非凡的加密，否则都是以明文的形式显示在HTML的源代码中。
HTTP Cookies
与隐藏字段的方法一样，使用HTTP Cookies的方式也是相对简单的。不幸的是，这两个方法有着许多相同的缺点。非凡是，在保存大量的状态信息时将会对性能产生很大的影响，因为在每次的请求和响应时，都必须在网络上传送全部的Session状态信息。
在客户端保存Session状态时，我们也会碰到大小和类型的局限问题。cookie headers的大小是有限制的，这样就限制了可以被持久保存的数据量，而且和隐藏字段的方法一样，当你使用cookies来保存Session状态时，这些持久的状态信息只能使用字符串值。
在客户端保存Session状态会带来的安全问题
当你在客户端保存Session状态时，你必须考虑到由此带来的安全问题。假如你不想数据暴露给客户端，你就需要一些方法来加密数据，从而保证数据的安全。
虽然在客户端保存Session状态相对轻易实现，不过它有着很多的缺点，这些都要我们花费时间去解决。对于需要处理大量数据的项目，非凡是企业的系统，使用这种方式是得不偿失的。
表现层的Session状态
当Session状态保存在服务器端时，它使用一个Session ID得到，并且会一直保持住，直到发生以下的情形：
. 一个预定义的Session超时发生了
. Session被手动设置为无效
. 状态由Session中移除
要注重的是服务器关闭后，一些内存中的Session治理机制可能不能恢复。
很明显，对于要保存大量Session状态的应用，将它们的Session状态放在服务器是更好的。当状态被保存在服务器上时，你不会有客户端Session治理的大小和类型限制。此外，还避免了由此带来的安全问题，而且也不会碰到由于在每个请求间传送Session状态带来的性能影响。
使用该方式，你可以更加灵活地作处理，并且便于扩展和提高性能。
假如你在服务器上保存Session状态，你必须要决定如何使该状态信息被每个服务器得到，即你运行该应用的服务器。假如群集的软件是运行在负载均衡的硬件上，那么就要处理这个Session状态的复制问题，这是一个多维的问题,不过，众多的应用服务器现在都提供了各种各样的解决方案。也就是说，在应用服务器的级别上有解决的方法。其中的一个方法是保证用户只与一个服务器打交道，它在流量治理软件上用得比较多，例如Resonate [Resonate]的软件，在用户的Session中，该用户发出的每个请求都会被路由到同一个服务器处理。这种方式也被称为server affinity。
另一个可选的方式是在商业层或者资源层保存Session状态。企业JavaBeans组件可用来在商业层保存Session的状态，而一个关系数据库则可用在资源层。
控制客户访问
有很多时候我们都要限制或者控制客户端访问某些应用资源。下面我们就来讨论其中两种这样的情形。
限制或者控制客户访问的一个原因是防止一个视图或者部分的视图被一个客户直接访问。这个问题会发生在以下情况，例如仅有注册或者登陆后的用户才可答应访问一个非凡的视图，或者是根据用户的角色限制用户访问部分的视图。
在描述过这个问题后，我们将讨论第二种情况，它和控制应用中一个用户的流程有关。后者的讨论和重复的form提交有关，因为多次提交将会导致不必要的重复事务。
控制视图访问
在一些情况下，资源被限制为完全不答应某些用户访问。有几个方法可以做到这一点。一个方法是加入应用逻辑到处理控制器或者视图的程序中，禁止某些用户访问。另一个方案是设置运行时的系统，对于一些资源，仅答应经由另一个应用资源内部调用。在这种情形，对于这些资源的访问必须被通过另一个表现层的应用资源进行，例如一个servlet控制器。对于这些受限制的资源不答应通过一个浏览器直接调用。
处理这个问题的一个常见方法是使用一个控制器来作为该类访问控制的一个委托者。另一个常见的方式是在一个视图中置入一个保护设置。我们这里主要讨论基于视图的控制策略。在考虑选择何种方式来控制访问之前，我们首先来描述一下这些策略。
在视图中置入保护逻辑
对于在一个视图的处理中置入一个保护逻辑，有两个常见的应用。一个是防止访问整个的资源，而另一个是限制访问部分的资源。
在每个视图中包含一个All-or-Nothing保护
在一些情况下，置入到视图处理代码中的逻辑以all-or-nothing的模式答应或者拒绝访问。也就是说，这个逻辑限制某个非凡的用户访问一个非凡的视图。通常这一类型的保护最好封装到一个中心化的控制器中，这样便于集中化治理。假如只有很少的页面需要防护，那么可以使用这个策略。通常这个情形都是发生在一个非技术人员需要更新网站一小部分的静态文件。假如客户仍然需要登陆到网站来浏览这些页面，那么只需要在每个页面的顶部加入一个自定义的tag（标记）就可以做到控制访问。如3.1的例子所示。
例子3.1 在每个视图中包含一个All-or-Nothing保护
<%@ taglib uri="/WEB-INF/corej2eetaglibrary.tld"
prefix="corePatterns" %＞
<corePatterns:guard/＞
<HTML＞
.
</HTML＞
给视图的某些部分加入保护
在其它情况下，置入到视图处理代码的逻辑可拒绝访问一个视图的某些部分。这个策略可以和上面的all-or-nothing策略一起使用。为说明这一点，我们这里使用控制访问一个建筑物中的一个房间作类比。all-or-nothing的保护策略告诉用户是否可以进入房间，而第二个保护策略则是告诉用户在进入房间后，答应他们看到什么东西。以下就是一些你可以利用这个策略的例子。
根据用户的角色决定是否显示视图的某些部分
根据用户的角色，视图的某部分可能不显示。例如，一个经理在收看治理信息时，他可以访问到其员工的子视图，而作为一个员工，他只可以看到自己组织的信息，而不可以访问其它信息，如例子3.2所示。
例子3.2 根据用户的角色，部分的视图不显示
<%@ taglib uri="/WEB-INF/corej2eetaglibrary.tld"
prefix="corePatterns" %＞
<HTML＞
.
<corePatterns:guard role="manager"＞
<b＞This should be seen only by managers!</b＞
<corePatterns:guard/＞
.
</HTML＞
根据系统的状态或者错误情形不显示部分的视图
根据系统的环境，显示的规划可以被修改。例如，假如用户使用的是一个单CPU的硬件设备，那么使用多个CPU的部分设备就可以不显示。
根据配置控制资源访问
要限制某个客户直接访问一个非凡的视图，你可以配置表现层只有通过内部的资源才可以访问到这些资源，例如一个使用RequestDispatcher的servlet控制器。此外，你还可以使用Web容器中内置
的安全技术，根据servlet2.2或者以后的规范。安全限制被定义在称为web.XML的配置描述文件中（deployment descriptor）。
basic和form-based的认证方法在Servlet规范中也有描述。在此我们不打算重复这个规范，你可以到以下网址去查看当前规范的细节（http://java.sun.com/prodUCts/servlet/index.html）。
你已经明白了加入安全限制到你的应用时会有什么用处，我们简要讨论了这个问题并且介绍了如何通过配置令它和all-or-nothing保护相关。最后，我们描述了一个简单和常用的方法作为all-or-no
