四、系统设计

在对系统的需求进行了分析以后，接下来开始对系统的整体架构进行设计。本章的重点在于讲述如何进行开发，而不是在于如何进行设计。因此，在设计这一部分只是简单进行了介绍，目的是为了使读者更容易理解整个系统。

1、系统架构设计

整个应用程序遵循多层次的架构模式，从上到下依次为视图层、控制器层、模型层、持久化层和数据库层，如图18所示。前面三层其实就是Struts框架的基本基本层次。持久化层则是Hibernate来创建的。

图18：系统架构

其中，模型层、持久化层、数据库层之间的关系是上层依赖下一层，而下一层对上一层的依赖很少，如同网络的ISO七层模型。各层次间的依赖关系应该是自顶向下的，即上层可以依赖下层，而下层应该尽量减少对上层的依赖。

例如，此时在系统中使用Hibernate来实现持久化层，若要采用其他机制实现持久化层时，则不需要改动业务逻辑中的代码。而视图层和控制器层都是通过Struts框架来实现的。模型层实际上又可细分为数据访问层(DAO)和数据服务层(Manager)。持久化层是使用Hibernate实现的，在这层使用了DAO模式，所以这层又可分为数据访问层和数据服务层。

2、业务实体设计

一个系统的业务实体在内存中表现为实体域对象，在数据库中表现为关系数据，实现业务实体包括以下内容。

◆设计域模型，创建域模型实体对象。
◆设计关系数据模型。
◆创建对象—关系映射文件。

在网络商店中有以下的业务实体:用户、具体商品、商品系类、商品类、订单、订单项、购物车和购物车中具体的商品。下面对这些业务实体作一个简单的解释，后面章节会有详细的解释。

◆用户：代表一个用户实体，主要包括用户的详细信息，如用户名，密码，地址之类的。
◆具体商品：代表每一个具体的商品信息，如上面提到的计算机程序设计艺术，主要包括商品的名字，价

格等。
◆商品系类：代表一系类商品，如前面提到计算机相关书籍。
◆商品类别：代表一类商品，如前面提到的书。
◆订单：代表用户的订单，主要包括订单名，用户信息，订单的具体内容。
◆订单项：代表订单中具体项，一个订单项包括一个商品的购买情况。
◆购物车：代表用户的购物车，是一个虚拟的概念。
◆购物车中的具体商品：代表购物车中每一个具体的购物项。

这些实体之间的关系如图19所示。

图19：业务实体关系图

如图19所示，这里来介绍一下各实体之间的对应关系。

◆用户和订单：一个用户可以拥有多个订单，一个订单只能属于一个用户，他们之间的关系是一对多的关系。在数据库表中是表现为订单表中有一个用户表的外键，在Hibernate中则表现为订单持久化类中有一个用户持久化类引用。
◆订单与订单项：一个订单中可以有很多订单项，一个订单项只是对一个具体商品的封装。订单与订单项的关系在Hibernate中表现为一个订单项中有一个订单的持久化类引用。
◆订单项与商品：一个订单项就是对商品的封装，一个商品就是这个商品的详细信息，订单项中除了有这个商品的信息，还有这个商品的购买数量，属于哪个订单等。
◆商品系列与商品：一个商品系列有多个商品，如同计算机方面书籍与计算机程序设计艺术关系。
◆商品类别与商品系列，一个商品类别有多个商品系列，如同书与计算机方面书籍的关系。
◆购物车与购物商品，用户的购物车中可以有多个购物商品，由于是网上购物，也许购物车中把一个没有库存的商品放到了购物车中，所以购物商品就必须有这个信息。
◆购物商品与商品，这个关系同订单项与商品的关系类似，只是购物商品对商品的封装角度不一样，购物商品中除了要记录商品的数量还需记录它的库存情况。

以上是系统中所有实体域模型之间的关系的定义。