本文共 3423 字，大约阅读时间需要 11 分钟。
来源于url：
创建模型组件
"If I had a world of myown, everything would be nonsense. Nothing would be what it is, becauseeverything would be what it isn't. And contrary wise, what is, it wouldn't be.And what it wouldn't be, it would. You see?"
这是一段来源与《爱丽丝梦游仙境》的台词。主要讲述了理想的模型构建和现实的差别如同爱丽丝梦境和现实世界的区别。
1. 概述
许多用来创建web应用的需求文档主要关注View。不过，你必须保证每个请求的需求
在模型层次上也是清晰定义的。总之，模型组件的开发者主要创建能够为基础需求提供支持的javaBeans类。这些被特定应用需要bean的本质变化主要取决于应用的需求，但是它们可以分为在接下来讨论当中的几种类别。然而，一个关于“scope”概念与它关联bean和JSP的简要回顾作为第一步是非常有必要的。
2. JavaBeans和 Scope
在一个web构建的应用中，JavaBeans能存储在一些不同的集合中属性上。每一种集合都有不同的生命周期规则和beans存储在集合上的可见性。综而论之，定义生命周期的规则和可见性被叫做这些beans的范围。JSP规范定义了在下面的术语作为范围的选择：
page:对当前请求的生命周期，beans在一个单独的JSP页面上是可见的
request:beans在当前页面是可见的，同时在任意的被引入到当前页的JSP页面和请求从当前页跳转到的页面。
session:beans在一个用户session内被调用的所有页面和servlet,经历一次或多次请求。
application:beans对当前web应用的所有页面和servlet都是可见的。
在同一个web应用当中的JSP页面和Servlet是共享上面四个集合的，这个要记住。例如，一个bean在servlet中作为一个request的属性存储：
MyCart myCart=new MyCart();
Request.setAttribute(“cart”,myCart);
在这个servlet转发的JSP页面上使用像下面标准的action标签它是立即可见的，
<jsp:useBean id=”cart” scope=”request”class=”com.mycompany.MyApp.MyCart”/>
3. ActionFormBeans
注意：ActionForm常常和模型的Bean有相同的属性，然而formbean本身应该作为一个控制器组件。因此，它们能够在模型层次和视图层次之间传输数据。
Structs框架一般假定在你的应用中你已经为输入表单定义了一个ActionFormbean. ActionForm bean有时叫做”form beans” 。它们可能是非常小的bean，因而每个bean对应一个表单，或者一个非常大的bean对应好几个表单或者整个应用的所有表单。
如果你在Struts的配置文件中声明了这种bean,在调用相应的Action方法时,Struts控制器servlet将自动的为你执行这些服务：
步骤1：在相应的范围内，使用相应的索引，检查是否有相应类型的bean的实例
步骤2：如果没有这样的可用实例，则自动创建一个实例并添加到对应的范围中
步骤3：对于每一个请求中的参数的名字如果同一个bean中的属性名字一致，这个属性的setter方法会被调用。当你使用星号通配符选择属性的时候，这种操作的方式与标准的JSP<jsp:setProperty>类似。
步骤4：被填充过的ActionForm bean将会传递给Action类[org.apache.struts.Action]的execute方法，以便于这些值可以被系统状态和业务逻辑的beans使用。
你应当注意到一个”form”不需要在用户界面对应一个单独的JSP页面。在许多应用当中,存在一个”form”继承多个页面是非常普遍的。假定，例如，在安装新的应用的时候，用户向导界面是非常通用的。Structs鼓励用户定义一个单独的包含所有属性的ActionFormbean,不论这些属性到底在什么页面上展示。同样的，各种页面如果含有相同的表单应该提交到相同的Action类。如果你采纳这些建议，页面设计人员可以重组在各种页面之间的属性，常常不需要修改业务逻辑。
小的应用可能只需要一个ActionForm就可以为所有的输入表单提供对应服务。其他应用可能需要为每一子应用提供一个单独的ActionForm.有的团队可能喜欢使用对每个不同的输入表单或者工作流提供单独的ActionForm。ActionForm使用的多或者少都取决于你。框架并不对此有什么要求。
4. SystemState Beans
一个系统的真实状态是由一系列的含有保存当前状态属性的类组成的。例如，一个购物车系统将会引入一个bean由每个购物者来维护并包含购物者即将消费的多项物品。个别的系统可能还会引入bean来保存用户的信息，以及消费目录和存货清单。
对于小规模的系统或者状态不需要保存很长时间，一系列的状态bean可能保存系统特定状态下的所有的信息。或者，在通常情况下，系统会保存状态bean持久的存储在外部的数据库当中，并根据需要的情况在服务器上的创建或者移除它们。实体的企业JavaBean也是在同样的目的下更大规模的应用中使用。
5. BusinessLogic Beans
为了实现这种目标，你应当封装你的应用的功能逻辑就像在JavaBean中调用的方法。这些方法可能是用于存储系统状态的类的一部分，也可能存在与特定的类中用于调用逻辑。在后一种情况下，你可能传输系统状态的bean作为参数来调用这些方法。
为了最大化的重用代码，业务逻辑bean的设计和实现必须能够满足任意环境下的web应用。如果你发现你不得不在你的类中导入javax.servlet.*类，这表示你正在将业务逻辑绑定到web应用的环境中。考虑重新组合这些以便于你的Action类可以从HTTP请求传输所有必需的信息通过业务逻辑bean的setter到属性当中，在这之后调用execute方法。这样的业务逻辑bean在环境中可以被重用，而不是每一次初始构建。
取决于系统的复杂性和应用的范围，业务逻辑bean可能作为一个普通的bean以系统状态bean作为参数进行交互，或者调用JDBC访问数据库。在大的应用当中，这些bean会被有状态或者无状态的企业JavaBean替代。
DynaBean结合了JavaBean的可继承性和HashMap的灵活性。定义最简单的bean仍然需要定义一个类，一个属性和属性对应的两个方法。DynaBean的属性可以通过一个XML文档进行配置。一个DynaBean的虚拟属性不可以通过标准的Java方法调用，不过通过反射和映射可以很好的在组件之间工作。在你的应用当中，你也可以使用它而避免创建大量的JavaBean存储对应的输入表单信息。
6. CommonsChain
Chain of Responsibility是一种组织复杂的处理流程执行的流行技术，在经典的“四人帮”的设计模式中有描述。“四人帮”描述Chain of Responsibility模式是为链中每一个对象都提供提交请求的机会，链中的请求沿着一直传递到有对象可以提交这个请求。这种模式帮助我们保持软件中组件的松耦合。一个组件可以调用一个Chain of Responsibility而不必得知链上的其他对象是什么，它们是怎么实现的。最重要的是，我们可以调整链而不必得知调用者是怎么调用它的。在1.3版本中，默认的请求处理器，作为框架的内核是一种Chain of Responsibility。
为了实现它的链，请求处理器在提供Chain of Responsibility标准实现，以及为请求服务的各种对context和命令实现的Apache Commons中使用了Chain of Responsibility组件，用来为一个请求服务。
转载地址：http://qhpdi.baihongyu.com/