在这篇文章，我们继续STRUTS，今天说说Struts里面的模型组件，严格来说Struts里面是没有模型框架的，但它允许使用现成的其他模型框架，我们还是先来看看什么是模型吧
模型代表应用的业务数据和逻辑。Struts框架并没有为设计和创建模型提供现成的框架，因为在前面我们已经说过，Struts主要用于做UI层！不过，Struts允许使用其他模型框架来处理应用的业务领域，如EJB(Enterprise JavaBean)它里面主要是实体Bean,，和JDO(Java Data Object),以及常规的JavaBean和ORM(Object-Relation Mapping)对象关系映射的Hibernate等等！
模型是应用中最重要的一部分，它包含了业务实体和业务规则，负责访问和更新持久层化数据(这里的持久化数据主要是针对ORM技术提出的)。应该把所有的模型组件放在系统中的同一个位置(也就是一般以***BO结尾的一个包)，这样有利于维护数据的完整性，减少数据冗余，提高可重用性！
模型应该和视图以及控制器之间保持独立。在分层的框架结构中，位于上层的视图和控制器依赖于下层模型的实现，而下层模型不应该依赖于上层的视图和控制器的实现！
因此如果模型组件中通过JAVA的import语句引入了视图和控制器组件，这就违反了以上原则。下层组件访问上层组件会使应用的维护，重用和扩展变的困难，这个和设计模式是一样的！
不过在struts中有一个问题，就是我们在创建模型组件 的时候假如和Hibernate相关联的话，Hibernate导过的类是集成序列化的一个接口！这样的一个Project如果它和一个Struts表单相关联的时候，因为struts表单它里面必须是ActionForm,这样的话我们转换就有问题，这个时候就最好屐一个地方～就是将Hibernate Project继承struts里面的actionForm. 当然这样做有点违反了规则，所以说struts框架，纯MVC来说，因为它本身包含了MVC的所有部分，当然它是一种入侵式的框架，依赖性比较强，也就是我们用了它之后必须依赖它，但在商业化上用Struts还是比较多的，从外面企业对人 才的可知！毕竟商业上面对系统的稳定性要求比较高，有点像说远了！和和～～
而在科学和工程技术领域，模型是一个很有用途的概念，它可以用来模拟一个真实的系统。建立模型最主要的目的是帮助理解，描述或模拟真实世界中的目标系统的运行机制。我们创建一个系统的时候首先会建立模型。
在软件开发领域，模型用来表示真实世界的实体。在软件开发的不同阶段，需要为目标系统创建不同的类型模型。在分析阶段，需要创建概念模型。在设计阶段，需要创建设计模型。可以采用面向对象建模语言UML来描述模型！
在建立模型前，首先要对问题域进行详细的分析，确定用例，也就是在模型建立前先要确定要用到的对象有哪些，接下来就可以根据用例来创建概念模型。概念模型用来模拟问题域中的真实实体。概念模型描述了每个实体的概念和属性，以及实体之间的关系。但在这个阶段并不描述实体的行为。
创建概念模型的目的是帮助更好地理解问题域，识别系统中的实体，这些实体在设计阶段很有可能变成类
概念模型清楚地显示了问题域中的实体。不管是技术人员还是非技术人员都能看懂概念模型，他们可以很容易地提出概念模型中存在的问题，帮助系统分析人员及早对模型进行修改。在软件设计与开发周期中，模型的变更需求提出的越晚，所消耗的开发成本也就越大！
现在来看看业务对象：它有以下三种！
业务对象，即Business Object(BO),是对真实世界的实体的软件抽象。它可以代表业务域中的人，地点，事物或概念！
业务对象包括状态和行为，标识符（ID号）。
判断一个类是否可以成为业务对象的一个重要标准，是看这个类是否同时拥有状态和行为！
实体业务对象要算是最为人们所熟悉的。实体对象可以代表人，地点，事物或概念。通常，可以把业务领域中的名词，例如客户，订单，商品等作为实体业务对象。在JAVAEE应用 中，这些名词可以作为实体BEAN。对于 更普通的WEB应用，这些名词可以作为包含状态和行为的JAVABEAN。
而过程业务对象代表应用中的业务过程或流程，它们通常依赖于实体业务对象。可以把业务领域中的动词。例如客户发出订单，应用等作为过程业务对象。在JAVAEE应用中，这们通常作为会话BEAN或者消息驱动 BEAN。在非JAVAEE应用中，他们可作为常规的JAVABEAN，具有管理和控制应用的行为，过程业务对象也可以拥有状态，例如在JAVAEE应用 中，会话BEAN可分为有状态和无状态两种。（这个在EJB中也有，在建立EJB的会话BEAN时 会有两种选择，有状态和无状态！）
事件业务对象代表应用中的一些时间（如异常，警告或越时）。这些时间通常由系统中的某种行为处罚。例如，在JAVA Swing应用中，当客户按下一个BUTTON，就会有一个事件业务对象产生，以便通知框架调用相关的时间处理器来处理事件
在应用系统中使用业务对象有许多好处，最重要的一点就是业务对象提供了通用的术语和概念，不管是技术人员还是非技术人员都可以共享并理解他们。它们可以直观地代表真实世界中的概念，开发小组的所有成员都能理解他们。如果正对同一个业务领域需要开发出多个应用，那么这些应用可以共享这些业务对象，业务对象的可重用特性可以提高应用开发速度。减少冗余。
另外业务对象可以隐藏实现细节，对外只暴露接口。EJB即如此！
在充分了解到业务对象在应用中的重要性后，接下来需要关心的问题是，这些业务对象的状态从何而来，当应用程序运行时，这些状态被存储在什么地方。这就涉及到了对象持久化问题！
通常持久化意味着通过手工或其他方式输入到应用中的数据，能够在应用结束运行后依然存在。即使应用运行结束或者计算机关闭后，这些信息依然存在。不管是大，中或小型应用，都需要数据持久化！
当应用中的业务对象在内存中创建后，糨们不可能永远存在。最后，他们要么从内存中清除，要么被持久化到数据库存储。内存无法永久保存数据，因此需要对业务对象进行持久化。否则，如果对象没有被持久化，用户在应用运行时发出的订单信息将 在应用结束运行后随之消失。
而关系型的数据库被广泛用来存储数据。关系型数据库中存放的是关系型 数据，它是非面向对象的。把业务对象映射到非面向对象的数据库中，存在着阻抗不匹配(impedance mismatch),因此对象由状态和行为组成，而关系型数据库则由表组成，对象之间的各种关系并不一一对应。例如对象之间的继承关系就不能直接映射到关系型数据库中。
而面向对象的开发方法是当今的主流，但是同时不得不使用关系型数据库，在企业级应用开发的环境中，对象－－关系的映射(ORM)是一种耗时的工作。围绕对象－－关系的映射和持久化数据的访问，在软件领域中发展起来了一种数据访问对象(Data Access Object, 即DAO)设计模式！
DAO模式提供了访问关系型数据库系统所需的所有的接口，其中包括创建数据库，定义表，字段和索引，建立表间的关系，更新和查询数据库等。DAO模式将 底层数据访问操作与高层业务逻辑分离，对上层提供面向对象的数据访问接口。在DAO的实现 中，可以采用XML语言来配置对象和关系型 数据之间的映射！
具体例子我放在Hibernate 初识 一文