副标题#e#
设计表示层时需要思量的几个问题
开拓者在设计表示层时，可以利用差异的模子，这时需要思量一些相关的设计问题。这些问题和模子干系的细密水平也各有差异，它们可以影响系统的各个方面，包罗有安详、数据完整性、可打点性和扩展性。固然这些设计问题大部门都可以用模子的形式暗示，但我们不规划这样做，因为这样更为抽象，我们选择以非正式的文档形式暗示。我们只是按照差异的模子，将每个需要思量的问题列出来。
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状态相对容易实现，不外它有着许多的缺点，这些都要我们耗费时间去办理。对付需要处理惩罚大量数据的项目，出格是企业的系统，利用这种方法是得不偿失的。
#p#副标题#e#
表示层的Session状态
当Session状态生存在处事器端时，它利用一个Session ID获得，而且会一直保持住，直到产生以下的景象：
. 一个预界说的Session超时产生了
. Session被手动配置为无效
. 状态由Session中移除
要留意的是处事器封锁后，一些内存中的Session打点机制大概不能规复。
很明明，对付要生存大量Session状态的应用，将它们的Session状态放在处事器是更好的。当状态被生存在处事器上时，你不会有客户端Session打点的巨细和范例限制。另外，还制止了由此带来的安详问题，并且也不会碰着由于在每个请求间传送Session状态带来的机能影响。
利用该方法，你可以越发机动地作处理惩罚，而且便于扩展和提高机能。
假如你在处事器上生存Session状态，你必需要抉择如何使该状态信息被每个处事器获得，即你运行该应用的处事器。假如群集的软件是运行在负载平衡的硬件上，那么就要处理惩罚这个Session状态的复制问题，这是一个多维的问题,不外，浩瀚的应用处事器此刻都提供了各类百般的办理方案。也就是说，在应用处事器的级别上有办理的要领。个中的一个要领是担保用户只与一个处事器打交道，它在流量打点软件上用得较量多，譬喻Resonate [Resonate]的软件，在用户的Session中，该用户发出的每个请求城市被路由到同一个处事器处理惩罚。这种方法也被称为server affinity。
另一个可选的方法是在贸易层可能资源层生存Session状态。企业JavaBeans组件可用来在贸易层生存Session的状态，而一个干系数据库则可用在资源层。
节制客户会见
有许多时候我们都要限制可能节制客户端会见某些应用资源。下面我们就来接头个中两种这样的景象。
#p#分页标题#e#
限制可能节制客户会见的一个原因是防备一个视图可能部门的视图被一个客户直接会见。这个问题会产生在以下环境，譬喻仅有注册可能登岸后的用户才可答允会见一个出格的视图，可能是按照用户的脚色限制用户会见部门的视图。
在描写过这个问题后，我们将接头第二种环境，它和节制应用中一个用户的流程有关。后者的接头和反复的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）。
#p#分页标题#e#
你已经大白了插手安详限制到你的应用时会有什么用处，我们扼要接头了这个问题而且先容了如何通过设置令它和all-or-nothing掩护相关。最后，我们描写了一个简朴和常用的要领作为all-or-nothing掩护，以限制一个资源的会见。
通过安详限制掩护资源
应用或者被设置在一个安详限制中，而这个安详限制答允利用编程的要领按照用户的脚色来节制会见。资源可以被某些脚色的用户会见，而且克制其它的脚色会见。别的，某个视图的一部门也可以按照用户的脚色来限制会见。假如某些资源完全克制全部的直接欣赏器请求，譬喻上面all-or-nothing情景中提到的一样，那么这些资源可以只答允一些安详脚色会见，而这些安详脚色不分派给任何一个用户。这样只要不分派这个安详脚色，那么以这种方法设置的资源将克制所有的欣赏器直接会见。例子3.3就是一个web.xml设置文件的一部门，它界说了一个安详的脚色以限制直接的欣赏器会见。
脚色的名字是“sensitive”，受限制资源的名字是sensitive1.jsp, sensitive2.jsp和sensitive3.jsp。除非一个用户可能组被分派到“sensitive”脚色，不然这些客户都不行以直接会见这些JSP页面。不外，由于内部的请求并不受这些安详的限制，一个初始时由某servlet节制器处理惩罚的请求将会导向到这些受限制的页面，这样它们就可以间接会见这些JSP页面。
最后，要留意的是，差异厂家的产物在实现Servlet2.2版本的类型时，在这个方面有些不兼容的现象。不外支持Servlet2.3的处事器则没有这个兼容性的问题。
例子 3.3 通过不分派安详脚色提供All-or-Nothing节制
＜security-constraint＞
＜web-resource-collection＞
＜web-resource-name＞SensitiveResources ＜/web-resource-name＞
＜description＞A Collection of Sensitive Resources ＜/description＞
＜url-pattern＞/trade/jsp/internalaccess/ sensitive1.jsp＜/url-pattern＞
＜url-pattern＞/trade/jsp/internalaccess/ sensitive2.jsp＜/url-pattern＞
＜url-pattern＞/trade/jsp/internalaccess/ sensitive3.jsp＜/url-pattern＞
＜http-method＞GET＜/http-method＞
＜http-method＞POST＜/http-method＞
＜/web-resource-collection＞
＜auth-constraint＞
＜role-name＞sensitive＜/role-name＞
＜/auth-constraint＞
＜/security-constraint＞
配置资源掩护的一个简朴要领
有一个简朴和常见的要领可以限制一个客户直接会见某个资源，譬喻JSP。和3.3的例子一样，这个要领无需修改任何的设置文件。这个要领只是需要将资源安排在Web应用的/WEB-INF/目次下。譬喻，要防备欣赏器直接会见一个称为info.jsp的视图，我们假设这个文件是属于一个名字为securityissues的Web应用。我们可以将该JSP文件放在以下的子目次：/securityissues/WEB-INF/internalaccessonly/info.jsp。
对付/WEB-INF/目次及其子目次是克制欣赏器直接会见的，因此info.jsp也不行以直接会见。不外，假如需要，一个节制器servlet仍然可以导向到这个资源。这种节制利用的是all-or-nothing的方法，因为以这种方法设置的资源都完全克制欣赏器直接会见。
反复的Form提交
用户利用欣赏器时，可以常常利用向后的按钮，因此就有大概反复提交一个他们已经提交过的form，这样就会带来一个反复事务处理惩罚的问题。同样，一个用户也大概在吸收到一个确认的页面之前按下遏制的按钮，接着再次提交同一个form。对付这些环境，我们都想跟踪而且克制这些反复的提交，我们可以利用一个节制servlet来提供一个节制点，以办理这个问题。
同步暗号（Synchronizer (or Dvu) Token）
这个计策是为了办理反复的form提交问题。一个同步的暗号被配置在一个用户的Session中，而且包括在返回到客户的每一个form中。当form被提交时，form中的同步标志就和Session中的同步标志作比拟。在form首次提交的时候，这两个标志应该是一样的。假如标志纷歧样，那么该form就会克制提交，一个错误就会返回给用户。在用户提交一个form时，假如按下欣赏器中的退却按钮并实验从头提交同一个form时，标志就会呈现不匹配的现象。
另一方面，假如两个标志值匹配，那么我们就可以确信整个流程是正确的。在这种环境下，Session中的标志值就会被修改为一个新的值，同时答允提交该form。
你也可以利用这个计策来节制对某些页面的直接会见，就好象上面资源掩护中描写的一样。譬喻，假设一个用户将某个应用的页面A保藏到保藏夹中，而页面A只答允通过页面B和C会见。当用户直接通过保藏夹来会见页面A，这时页面的会见顺序就是不正确的，这样同步标志将处在一个差异步的状态，可能它基础就不存在。岂论奈何，会见都被克制了。
验证
#p#分页标题#e#
凡是我们都但愿同时在客户和处事器端举办验证。固然客户端的验证处理惩罚看来没有处事器端验证那样专业，不外它可以提供高级此外查抄，譬喻验证form中的某个字段是否为空。处事器端的验证凡是要遍及得多。固然在一个应用中，两种范例的处理惩罚都是适当的，不外这里不发起只利用客户端的验证。这样做的一个主要原因是由于客户端的验证是利用客户端的剧本语言的，用户可以在任何时候通过配置，从而跳过这些剧本。
这里不规划很具体地接头验证的计策。我们只是在这里提及一下这是一个在设计系统时需要思量到的问题，假如你想更深入地相识，你可以参考现有的文献。
在客户端验证
输入的验证在客户端举办。凡是这个操纵都是通过嵌入的剧本代码譬喻JavaScript举办。上面已经提到，客户端的验证是处事器端验证的一个增补，不外不该该独立利用。
在处事器端验证
输入的验证在处事器端举办。有几个典范的计策可用作处事器端验证。这些计策是Form-Centric Validation（以Form为中心的验证）和validation based on abstract types（基于抽象范例的验证）。
Form-Centric Validation
Form-Centric Validation的计策强迫一个应用包括很多的要领来验证form各部门的状态。典范地，这些要领依据其包括的逻辑，都是交迭的，这样倒霉于从头利用和模块化。一个验证的要领都是和用户某个特定的form相关，没有配合的代码来处理惩罚常见的操纵，譬喻必填的字段可能只可以利用数字的字段。在这种环境下，当某个字段被用在多个差异的form，而且是一个必填的字段时，它都是在应用中独立处理惩罚的。这个计策实现起来相对容易，而且效率也高，不外当应用变大时，就会带来反复代码的问题。
要提供一个更机动的、可重用的和易于维护的要领，数据模子应该作更大的抽象。这个方法就是下面提到的“按照抽象范例来验证，form-centric验证的例子见例子3.4。
Example 3.4 Form-Centric Validation
/**If the first name or last name fields were left
blank, then an error will be returned to client.
With this strategy, these checks for the existence
of a required field are duplicated. If this valid-
ation logic were abstracted into a separate component,
it could be reused across forms (see Validation Based
on Abstract Types strategy)**/
public Vector validate()
{
Vector errorCollection = new Vector();
if ((firstname == null) || (firstname.trim.length() ＜ 1))
errorCollection.addElement("firstname required");
if ((lastname == null) || (lastname.trim.length() ＜ 1))
errorCollection.addElement("lastname required");
return errorCollection;
}
抽象类验证
这个要领可应用在客户端可能处事器端，不外在一个基于欣赏器可能瘦客户端的情况下，最好应用在处事器端。
输入和限制的信息由模子状态中抽象出来而且放到一个通用的架构中。这样将模子的验证和模子正在利用的应用逻辑分分开来，从而淘汰了它们的耦合。
模子验证通过将元数据及限制和模子状态作比拟举办。模子的元数据和限制凡是可以通过一些简朴的数据存储会见到，譬喻一个属性文件。这种要领的长处是系统更通用了，因为它将状态和限制的信息由应用逻辑中疏散出来。
譬喻有一个组件可能子系统封装验证的逻辑，这些逻辑包罗判定一个字符串是否是空的，一个数字的输入在某个范畴，可能是一个名目化为某种方法的字符串等。当差异的应用组件需要验证某个模子的差异方面时，每一个组件并不需要写本身的验证代码。取而代之的是，利用会合式的验证技能。会合式的验证技能可以通过一些方法配置，譬喻通过编程，一些产生器可能凡是声明、利用设置文件等。
这样验证的技能就越发通用，它会合在模子的状态和它的需求，而与应用的其它部门无关。利用这个要领的一个缺点是效率和机能要受到影响，并且，凡是更通用的要领，固然成果更强大，可是领略和维护起来有点难解。
以下是一个例子。一个利用XML的设置文件描写了各类的验证，譬喻“必填的字段”，“要求全部是数字的字段”等。另外，可以设计每个验证的打点类。最后，一个影射将HTML表格的值和某类出格的验证对应起来。验证某个特定字段的例子代码如例子3.5所示。
例子 3.5 Validation Based on Abstract Types
//firstNameString="Dan"
//formFieldName="form1.firstname"
Validator.getInstance().validate(firstNameString, formFieldName);
Helper Properties–完整性和一致性
#p#分页标题#e#
JavaBean Helper类凡是是用来生存一个客户请求传送过来的中间状态。JSP的运行引擎提供了一个技能，可以自动地将这些参数值由一个servlet请求工具拷贝到这些JavaBean的helper工具的属性中。JSP语法如下所示：
＜jsp:setProperty name="helper" property="*"/＞
上面的语句汇报JSP引擎将所有匹配的参数值拷贝到一个JavaBean的相应属性中（这个JavaBean的名字是“helper”），如例子3.6所示。
例子3.6 Helper Properties – A Simple JavaBean Helper
public class Helper
{
private String first;
private String last;
public String getFirst()
{
return first;
}
public void setFirst(String aString)
{
first=aString;
}
public String getLast()
{
return last;
}
public void setLast(String aString)
{
last=aString;
}
}
那么奈何才算匹配呢？假如一个request参数的名字和范例和helper bean的属性一样，那么就认为它们是匹配的。凡是城市将每个参数和每个bean属性的名字及bean属性的setter要领的范例作较量。
固然这个能力很是简朴，不外它可以发生一些令人疑惑的对象。首先，要留意的假如request参数的值是空的话那将会奈何的呢？很多开拓者大概认为当一个request参数是一个空的String时，假如它和一个bean属性匹配，将会令该bean属性吸收一个空的String值或Null。实际上在这种环境下，功效是不会修改匹配的bean属性。尚有，由于JavaBean helper工具是超过多个请求重用的，这种暗昧的做法将令数据值不完整和不正确。图3.1展示了这类本了解带来的问题。
***************图3.1***************
请求1包括有名字为“first”和“last”的参数值，而且这些值配置了相应的bean属性。请求2仅包括有“last”参数的值，因此只配置了bean中的个中一个参数，而“first”参数的值则没有变革。—www.bianceng.cn。它并没有配置为一个空字段串可能是null，这是由于在请求的参数中并没有值。如3.1的图所示，假如bean的值在请求间并没有手动复位，这是将会带来纷歧致的问题。
在设计你的应用时，要思量的另一个问题是当form中的项目没有选择的时候，HTML form接口是如那里理惩罚的。譬喻，当一个form拥有多个checkbox，在没有选择任何的checkbox时，处事器端的值是不会被清空的。当request工具由这个接口发生时，在request工具中就没有包括相应的checkbox参数。因此，这些checkbox相关的参数值都不会发送随处事器端（完整的HTML类型，见http://www.w3.org/）。
由于没有参数值传送随处事器，所以如上所述，在利用＜jsp:setProperty＞ 时，匹配的bean属性将保持稳定。在这种环境下，除非开拓者手动修改这些值，不然应用中将有大概呈现纷歧致和不正确的数据值。一个简朴的办理要领是在每个请求间复位所有JavaBean的状态值。
设计表示层时需要制止的坏习惯
所谓的坏习惯，指的是未到达最优化的方案，它们与设计模式的发起是斗嘴的。当我们将模式和洽习惯记录下来时，我们就会自然地丢弃掉那些未到达最优化的习惯。
在这里，我们简朴谈一下与表示层相关的坏习惯。
在每个部门，我们都扼要描写一下坏习惯，而且提供相关的指引，包罗有设计问题，refactoring和模式等，提供进一步的信息和更好的选择。我们并不会很是深入地接头每个坏习惯，这里只是点到即止，有乐趣的可继承深入研究。
多个视图中利用节制代码
问题摘要
自界说tag helper可以包括在JSP视图的顶部，以执行会见节制和其它范例的查抄。假如大量的视图包括有雷同的helper引用，维护这些代码将会变的很是坚苦，因为修改可以产生在多个处所。
办理要领：
修改节制代码，利用一个controller和相关的Command helpers。当需要在多个处所包括雷同的节制代码时，譬喻只有一部门的JSP视图克制一些用户会见的时候，将这个事情通过一个可重用的helper类完成。
在贸易层袒露表示层的数据布局
问题摘要
#p#分页标题#e#
表示层的数据布局，譬喻HttpServletRequest，应该被限制到表示层上。假如将这些细节放到贸易层可能其它层中，将增加这些层间的耦合，这样就会淘汰可操作处事的重用性。假如贸易处事的要领接管一个HttpServletRequest范例的参数，这样利用这个处事的客户（纵然是那些非Web上的客户）都必需将它们的请求状态封装到一个HttpServletRequest工具中。另外，贸易层的处事需要知道如何与这些表示层的数据布局交互，从而令贸易层的代码变得巨大，而且增加了层间的耦合。
办理要领：
不让表示层的数据布局和贸易层共享，而是拷贝相关的状态到一个更常见的数据布局中而且再共享。你也可以选择由表示层数据布局中将相关的状态疏散出来，作为独立的参数共享。
在域工具袒露表示层的数据布局
问题摘要
将诸如HttpServletRequest的请求处理惩罚数据布局和域工具共享，这样将不须腹地增加了应用中两个差异方面的耦合。域工具应该是可重用的组件，假如它们的实现依赖协议可能层相关的细节，它们可重用的时机就会淘汰，并且，维护和调试高耦合的应用越发坚苦。
办理要领：
不通过传送一个HttpServletRequest工具作为一个参数，而是拷贝request工具的状态到一个更为常用的数据布局中，而且将这个工具共享给域工具。你也可以选择由HttpServletRequest工具中将相关的状态疏散出来，而且将每一个的状态作为一个独立的参数提供应域工具。
答允反复的Form提交
问题摘要
欣赏器客户情况的个中一个缺点是对缺少对客户欣赏某个应用时的节制。一个用户大概提交了一个订单，这个生意业务将会导致由一个信用卡帐号中扣除用度，而且将产物运送到客户手中。在吸收到确认页面后，假如用户点击退却的按钮，同一个form将会再次提交。
办理要领
这个问题的办理要领上面已经提到，这里不再详述
直接袒露敏感的资源给客户会见
问题摘要
在企业情况中，安详是个中一个最重要的问题。假如某些信息没有须要让一个客户直接会见到，那么这些信息应该掩护起来。对支付格的设置文件，属性文件，JSP可能class文件，假如不作一些掩护，那么客户将可以不经意可能存心地吸收到敏感的信息。
办理要领
关于掩护敏感资源的要领，上面已经提到。
错误地认为＜jsp:setProperty＞将会复位Bean属性
问题摘要
＜jsp:setProperty＞尺度标签可将request的参数值拷贝到同名的JavaBean helper属性中，不外，当参数的值为空时，获得的功效是很容易使人疑惑的。譬喻，一个值为空的参数将会被忽略，但许多开拓者都错误地认为匹配的JavaBean属性将会获得一个null可能空的字符串值。
办理要领：
在利用＜jsp:setProperty＞标签时，不要只是想虽然，在利用前，你应该初始化bean属性。
建设过大的节制器（Controller）
问题摘要
对付多个JSP视图中反复利用的节制代码，在许多时候城市放到一个节制器中。假如太多的代码被插手到一个节制器中，那么它就会变得很复杂而且难以维护、测试和调试。譬喻，对一个servlet节制器举办单位测试，出格是一个“臃肿的节制器”，相对付测试一个独立的和HTTP协议无关的helper类，将会巨大得多。
办理要领
在处理惩罚一个请求时，节制器凡是都是首先处理惩罚的处所，不外它应该也是一个委托点，与其它的节制类一起事情。可以利用Command工具来封装节制器委托的节制代码。测试这些独立于Servlet引擎的JavaBean command工具要容易得多，因为它需要测试的模块代码更少。
