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

17.4.1 系统架构设计

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

图17.24 系统架构

这几个层次关系是自顶向下的，上面的层次依赖下一层，而下一层对上一层的依赖很少，尽量做到没有，如同网络的ISO七层模型。bit论坛系统的设计同网络商店的系统设计很相似，读者可以参看网络商店的相应章节。

17.4.2 业务实体设计

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

q 设计域模型，创建域模型实体对象。

q 设计关系数据模型。

q 创建对象—关系映射文件。

在bit论坛中有以下的业务实体：注册用户、管理员、主题、话题以及话题的回复。下面对这些业务实体作一个简单的解释，后面章节会有详细的解释。

q 注册用户代表一个注册用户实体。主要包括用户的详细信息，如用户名、密码、地址之类的。

q 管理员代表一个系统管理员。它与注册用户一样的，只是权限不一样。

q 主题代表论坛中的一个主题。在主题下面有很多话题以及话题的回复，它们之间的关系是一对多的关系。

q 话题代表一个注册用户发标的话题。话题可以拥有回复，一个话题之能属于一个主题，一个话题可以拥有多个回复。

q 回复代表一个话题的回复。一个回复只能属于一个话题。

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

图17.25 业务实体关系图

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

q 主题与话题：一个主题可以拥有多个话题。一个话题只能属于一个主题，它们之间的关系是一对多的关系。在数据库中，一般的做法是通过在话题表中引用一个主题表的外键。但在这个系统中，由于使用Hibernate技术，所示没有在数据表中体现它们的关系。在Hibernate的映射文件中体现了两者的一对多的双向关系。

q 话题与回复：一个话题可以拥有多个回复，一个回复只能属于一个话题。它们之间的关系也是一对多的，同主题与话题。在具体实现时，也是和主题与话题的实现方法一样。

q 用户与话题：一个用户可以拥有多个话题，一个话题只能属于一个用户。它们之间的关系是一对多的关系。在具体实现时，要求删除一个用户时，该用户所属题也应该被删除。

q 用户与回复：一个用户可以拥有多个回复。一个回复只能属于一个用户。