Struts 模型组件
模型代表应用的业务数据和逻辑。Struts框架并没有为设计和创建模型组件提供现成的框架。不过，Struts允许使用其他模型框架来处理应用的业务领域，如EJB(Enterprise JavaBean)和JDO(Java Data Object)，以及常规的JavaBean和ORM(Object-Relation Mapping)。
1 模型在MVC中的地位
模型是应用中最重要的一部分，它包含了业务实体和业务规则，负责访问和更新持久化数据。应该把所有的模型组件放在系统中的同一个位置，这有利于维护数据的完整性，减少数据冗余，提高可重用性。
模型应该和视图以及控制器之间保持独立。在分层的的框架结构中，位于上层的视图和控制器依赖于下层模型的实现，而上层模型不应该依赖于上层的视图和控制器的实现。Struts应用的各个层次之间的依赖关系：
从上到下，依赖关系加强；从下到上，依赖关系减弱。
如果在模型组件中通过Java的import语句引入了视图和控制器组件，这就违反了以上原则。下层组件访问上层组件会使应用的维护、重用和扩展变得困难。
2 模型的概念和类型。
在科学和工程技术领域，模型是一个很有用途的概念，它可以用来模拟一个真实的系统。建立模型最主要的目的是帮助理解、描述或模拟真实世界中目标系统的运转机制。
在软件开发领域，模型用来表示真实世界的实体。在软件开发的不同阶段，需要为目标系统创建不同类型的模型。在分析阶段，需要创建概念模型。在设计阶段，需要创建设计模型。可以采用面向对象建模语言UML来描述模型。
2.1 概念模型
在建立模型之前，首先要对问题域进行详细的分析，确定用例，接下来就可以根据用例来创建概念模型。概念模型用来模拟问题域中的真实实体。概念模型描述了每个实体的概念和属性，以及实体之间的关系。但在这个阶段并不描述实体的行为。
创建概念模型的目的是帮助更好地理解问题域，识别系统中的实体，这些实体在设计阶段很有可能变成类。
概念模型清楚地显示了问题域中的实体。不管是技术人员还是非技术人员都能看得懂概念模型，他们可以很容易地提出概念模型中存在的问题，帮助系统分析人员及早对模型进行修改。在软件设计与开发周期中，模型的变更需求提出得越晚，所耗费的开发成本就越大。
2.2 设计模型
概念模型是在软件分析阶段创建的，它帮助开发人员对应的需求获得清晰精确的理解。在软件设计阶段，需要在概念模型的基础上创建设计模型。可以用UML类框图，活动图以及状态图来描述设计模型。
根据UML语言，类直接存在四种关系。
1
关联(Association)
关联指的是类之间的引用关系。
2 依赖(Dependency)
依赖指的是类之间的访问关系。
3 累积(Aggregation)
累积指的是整体与个体之间的关系，可以把累积看作一种强关联关系。
4 一般化(Generalization)
一般化指的是类之间的继承元素。
3 业务对象(BO)
业务对象，即Business Object(BO)，是对真实世界的实体的软件抽象。它可以代表业务领域中的人、地点、事物或概念。
业务对象包括状态和行为。
判断一个类是否可以成为业务对象的一个重要标准，是看这个类是否同时拥有状态和行为。
3.1 业务对象的特征和类型
如果一个类可以作为业务对象，它应具有以下特征：
·
包含状态和行为
·
代表业务领域的人、地点、事物或概念
·
可以重用
业务对象可分为三种类型：
·
实体业务对象
·
过程业务对象
·
事件业务对象
实体业务对象要算是最为人们所熟悉的。实体对象可以代表人、地点、事物或概念。通常，可以把业务领域中的名词，例如客户、订单、商品等作为实体业务对象。在J2EE应用中，这些名词可以作为实体Bean。对于更普通的Web应用，这些名词可以作为包含状态和行为的JavaBean。
过程业务对象代表应用种的业务过程或流程，它们通常依赖于实体业务对象。可以把业务领域中的动词。例如客户发出订单、登入应用等作为过程业务对象。在J2EE应用中，它们通常作为会话Bean或者消息驱动Bean。在非J2EE应用中，他们可作为常规的JavaBean，具有管理和控制应用的行为。过程业务对象也可以拥有状态，例如在J2EE应用中，会话Bean可分为有状态和无状态两种。
事件业务对象代表应用中的一些时间（如异常、警告或超时）。这些时间通常由系统中的某种行为处罚。例如，在Java Swing应用中，当客户按下一个按钮，就会有一个事件业务对象产生，以便通知框架调用相关的时间处理器来处理事件。
3.2
业务对象的重要性
在
应用中使用业务对象有许多好处，最重要的一点就是业务对象提供了通用的术语和概念，不管是技术人员还是非技术人员都可以共享并理解他们。它们可以直观地代
表真实世界中的概念，开发小组的所有成员都能理解他们。如果正对同一个业务领域需要开发出多个应用，那么这些应用可以共享这些业务对象。业务对象的可重用
特性可以提高应用开发速度。减少冗余。
此外，业务对象可以隐藏实现细节，对外只保露接口。例如，如果业务对象的某个方法需要传入java.util.ArrayList类型的参数，那么应该把参数定义为java.util.List接口类型。这样，假定这个方法的实现发生改变，用LinkedList取代ArrayList来实现原有的功能，这种概念不会对方法调用者造成任何英雄。
在充分了解到业务对象在应用中的重要性后，接下来需要关心的问题是，这些业务对象的状态从何而来，当应用中指运行时，这些状态被存放到什么地方。这就涉及到了对象的持久化问题。
4 业务对象的持久化
通常，持久化意味着通过手工或其他方式输入到应用中的数据，能够在应用结束运行后依然存在。即使应用运行结束或者计算机关闭后，这些信息依然存在。不管是大、中或、小型的应用，都需要数据的持久化。
4.1 对业务对象进行持久化的作用。
当应用中的业务对象在内存中创建后，它们不可能永远存在。最后，他们要么从内存中清楚，要么被持久化到数据存储库中。内存无法永久保存数据，因此必需对业务对象进行持久化。否则，如果对象没有被持久化，用户在应用运行时发出的订单信息将在应用结束运行后随之小时。
关系型数据库被广泛用来存储数据。关系型数据库中存放的是关系型数据，它是非面向对象的。把业务对象映射到非面向对象的数据库中，存在着阻抗不匹配（impedance mismatch），因此对象由状态和行为组成，而关系型数据库则由表组成，对象之间的各种关系和关系型数据库中表之间的关系并不一一对象。例如对象之间的继承关系就不能直接映射到关系型数据库中。
4.2 数据访问对象（DAO）设计模式
面向对象的开发方法是当今的主流，但是同时不得不使用关系型数据库，在企业级应用开发的环境中，对象－关系的映射（Object-Relation Mapping，简称ORM）是一种耗时的工作。围绕对象－关系的映射和持久化数据的访问，在软件领域中发展起来了一种数据访问对象（Data Access Object，简称DAO）设计模式。
DAO模式提供了访问关系型数据库系统所需的所有操作的接口，其中包括创建数据库、定义表、字段和索引，建立表间的关系，更新和查询数据库等。DAO模式将底层数据访问操作与高层业务逻辑分离开，对上层提供面向对象的数据访问接口。在DAO的实现中，可以采用XML语言来配置对象和关系型数据之间的映射。
对于Java应用，可以直接通过JDBC编程来访问数据库。JDBC可以说是访问持久数据层最原始、最直接的方法。在企业级应用开发中，可以通过JDBC编程，来开发自己的DAO API，把数据库访问操作封装起来，供业务曾同一调用。
如果数据模型非常复杂，那么直接通过JDBC编程来实现持久化框架需要有专业的知识。对于企业应用的开发人员，花费大量时间从头开发自己的持久性框架不是很可行。通常，可以直接采用第三方提供的持久化框架，如ORM软件产品。许多ORM框架都采用DAO设计模式来实现，为模型层提供了访问关系型数据库的API。
4.3 常用的ORM软件
有许多ORM软件可供选择。有些是商业化的，有些是免费的。
不管是使用商业化产品，还是非商业化产品，都应该确保选用的ORM框架没有“渗透”到应用中，应用的上层组件应该和ORM框架保持独立。有些ORM框架要求在业务对象中印入它们的类和接口，这会带来一个问题，如果日后想改用其他的ORM框架，就必需修改业务对象。
5 小结
这篇文档介绍了模型的实现方法。Struts框架并没有在模型层提供线程可用的组件。模型的实现应该和Struts应用的控制层以及视图层保持独立。
模型采用业务对象来描述状态和行为，为了使业务对象持久化，需要把业务对象映射到关系型数据库。
模型向客户程序提供了业务代理接口，业务代理接口直接访问持久化框架，处理实际的业务逻辑。Struts应用的Action类可以使用这个业务代理接口，而不必直接和持久化框架交互。这种做法有助于削弱上层Web应用和持久化框架之间的关系，提高持久化框架的相对独立性。
阅读材料：《精通Struts：基于MVC的Java Web设计与开发》
2005年05月12日 1:20 AM