数据库应用软件开发框架的研究

摘要：在对数据库应用软件的核心概念进行分析研究的基础上，按面向对象的思想，抽取核心对象，并按模式对它们进行组织，最终形成一个开发框架。文章阐述了该框架各组成部分的功能及相互关系，总结了此框架的基本特征及开发实现的关键技术。

关键词：数据库；面向对象；设计模式；开发框架

中图分类号：TP311文献标识码：A 文章编号：1009-3044(2007)03-10641-02

1 引言

数据库应用软件的使用非常广泛。面向对象（OO）是优秀的软件设计思想，但如何用OO方法设计出好的数据库应用软件，众说纷芸。笔者根据自己多年的数据库应用软件的开发经验，在工作中整理出自己的一套方法，公之与众，以求抛砖引玉。

2 开发框架的核心概念分析

在面向对象的设计中，可以简化为两步，一是寻找对象，二是给对象分配职责。总体思路是：分析数据库应用软件中的基本概念，导出对象类型，进一步定义各类型的职责和关系。下面从数据库应用软件开发框架核心概念的分析入手，结合MVC的特点，构建基于界面、业务、实体、控制器、实体工厂和数据库的数据库应用软件开发框架和设计模式。

2.1 分析过程

数据库应用软件是围绕数据库展开的，对数据库的操作，无非是查询、增加、删除、修改、保存，分别对应SQL中的Select、Insert、Delete、Update、Commit。数据库应用软件从本质上来说，就是用可视化的界面让普通用户执行这些SQL，当然，这些SQL不是随便就可以执行的，要遵循一定的规则，这就是业务逻辑。所以，界面、业务逻辑、数据库构成了数据库应用程序。怎样去组织这三者就是本文要讨论的问题。

模式是解决一个特定问题的最佳方案，所以我们的任务就是要设计出一个组织界面、业务逻辑、数据库的模式。提起模式，自然会想起大名鼎鼎MVC，MVC是组织模型、视图、控制器的最佳方案，而我们的任务中，也是三个核心类型，能否直接用MVC解决呢？

显然界面对应视图，数据库对应模型，那么业务是否也与控制器对应呢？控制器决定界面对用户输入的响应方式，显然业务逻辑并不能与控制器对应。但在本框架中引入MVC显然也是一个好方案，可以另外引入控制器，但现在的问题是如何处理业务？

将业务放到界面中显然不是好主意，在此就不讨论了。那么能不能将业务放到实体里面呢？在讨论这个问题前先要对实体做一个定义。在一些书中，实体定义为对应表中的一行数据，可是我们经常要同时处理多条数据，如主从表中，一个主表中的行往往对应从表中的多行，按前面的定义，做一个涉及主从表的业务可能涉及多个从表实体，这样是不是值得呢？

其实只要把定义换一个字就可以了，实体定义为对应表中的一组数据。按照这样的定义，一个主表中的行对应从表中的多行可以放到一个从表实体中去。现在再回到前面的问题，业务是不是要放到实体里？回忆以前做的项目，数据库结构一旦确定后很少修改，但业务逻辑却经常变化，一般情况下，所谓的需求变更都是业务逻辑的变更。根据“封装变化”的原则，业务与实体应该分开。

至此，本框架中有了四个核心类型：界面、控制器、实体、业务逻辑。我们还需要引入最后一个类型，即实体工厂。

在面向对象的程序中，对象的创建和销毁其实是很麻烦的一件事，也非常消耗资源。其中最典型的就是实体，一般实体创建时需要从数据库中取数据填充到自己的实例变量中，销毁时需要销毁这些实例变量。在写程序时，如果有多个分支，往往会在某个分支中忘记了销毁，从而造成内存泄漏。另外，每次实体创建时都需要访问数据库读取数据，对数据库也是一个不小的负担。如果严格遵循OO，那么对数据库的访问都要通过实体，如果实体已经创建，那么只需要到实体中取数据就可以了，根本不需要再去访问数据库。这时，显然需要一个缓存，可以把这个任务分配给“实体工厂”。实体就是实体工厂的产品。

下面的问题就是实体与实体工厂如何对应，在现实世界中，一个工厂会生产多个产品，本框架的第一个版本就是这样做的，但实践后改为“一一对应”，即一个实体工厂只有一个实体产品，这样更好些。

2.2 核心概念模型

至此，本框架中的五个核心类型就全部形成了，即界面、控制器、实体工厂、实体、业务逻辑。另外，由于主要讨论数据库应用软件，一切是围绕数据库展开的，故也将数据库作为一个核心类型。它们的关系如图1所示：

2.3核心概念职责

五个类型的职责和关系如表1所示：

表1 核心概念职责

3 核心概念的职责说明

3.1 界面职责

如果严格按MVC中V的定义，界面应该是没有业务逻辑的，也不应该与数据库直接交互。在本框架的第一个版本中，确实是这样做的。但这样做的结果是很累。在数据库中有很多代码与意义的对应，在表中往往只是存储代码，在一个数据字典表中存储代码的意义，在界面中要显示意义而不是代码。而实体一般与表对应，存储的只能是代码，如果界面不直接访问数据库，要想在界面中显示意义是很麻烦的。所以现在的版本中，界面是可以直接访问数据库的，但只能读而不能写。

另外，界面中有输入检查的功能，如输入一个不存在的数据，会弹出一个查询界面列出合法的数据供用户选择。在最初的版本中，这个功能也是放到控制器中做的，同样做得很累。现在的版本把这个功能也放到界面中去了。

3.2 控制器职责

一般情况下，只是把用户的界面的操作转化为对后台的调用，严格来说，控制器不应该实现业务逻辑，但在实践时，我们发现有些业务逻辑也可以放到控制器中，这些业务逻辑有两个条件：(1)业务逻辑比较简单，如果用一个专门的业务类去处理有些“大材小用”；(2)此业务逻辑没有可重用性，只有在当前控制器服务的界面中才会调用到。

另外，控制器还有控制事务的作用。业务类和实体类是不会提交或回滚事务的，这个任务由控制器来负责。需要说明的是，如果没有界面（也就没有控制器），如在后台运行的一些服务，这时的事务就由实现此服务的业务类来控制。

3.3 实体职责

实体只是负责对数据库的存取，不会包含业务逻辑。实体只负责其自身相关的数据库表的存取。在本框架的最初版本中，实体是包含业务逻辑的，但在实践中渐渐放弃了这种做法。

关于实体，往往有两个问题：

(1)实体与数据库中表的对应关系是什么？

(2)实体代表了表中的多少数据？

在现实软件中，单据是很常见的，一个单据往往由两部分组成，一是单据的头尾，一是单据的内容。单据的头尾一般只有一行数据，单据的内容往往会有多行数据，就以“计划”为例，发票的头尾中有计划号，计划日期等，计划的内容会是多条任务，每条任务有自己的名称、起止日期。在设计对应的数据库表时，一般会设计两个表与之对应，一个是计划主表，对应计划的头尾，一个是计划从表，对应计划的内容。

那么，对应于计划，需要设计几个实体呢？有两个选择，一是设计一个实体，二是设计两个实体。一般情况下，是设计两个实体。但还是有问题，这两个实体之间的关系是什么？粗一看，好象这根本不是问题，这两个实体是主从表关系啊。

那我们再扩展一下计划，计划的明细是一条条的任务，而每个任务又会涉及多个相关人员，这样，就需要设计三个实体，分别对应计划主表、计划从表（任务表）、计划相关人表。它们之间的关系是主-从-从关系。而且我们还可以再扩展，这样最终会产生更多的实体，而实体之间的关系更加错综复杂。

解决这个问题的方法就是：实体之间不建立关系。这个关系可以通过数据库的完整性约束来实现，另外还可以用业务类来实现。

所以，对第一个问题的答案是：实体与表是一一对应的，实体之间不建立关系。

下面讨论第二个问题。前面说过实体对应表中的一组数据，也就是一个实体可以对应表的一条数据，也可以对应表中的一组数据。仍然以计划为例，一个计划实体对应计划表中的一行数据，一个任务实体则对应一个计划下的所有任务，也就是对应任务表的N（0~*）条数据。

但在实践中仍然是一个头疼的问题，因为有的业务是针对计划下的所有任务，有的业务是针对一条任务。当业务针对一条任务时，任务实体有时比较难以操作。

3.4 业务职责

业务的职责最简单，就是实现业务逻辑。但是，业务也是最让人迷惑的地方。

关于业务，有这么几个问题：

(1)何时需要定义一个业务类？

(2)业务类的粒度？

对第一个问题，答案是：当某个业务逻辑比较复杂时，就需要定义一个业务类。那么这里的业务逻辑又指什么呢？业务逻辑往往对应一个“系统用例”。那么“比较复杂”又怎么界定呢？答案是没有标准，只能提供一些参考。

(1)“是否复杂”可以通过用例分析得到，如果用例比较复杂，那么就需要建立业务类；

(2)如果一个业务涉及多个实体，就要考虑建立业务类；

(3)如果某业务有复用价值，就要建立业务类。

那么简单的业务在何处实现呢？可以通过控制器实现，甚至界面也可以。

讨论第二个问题。对业务类，遵循“单一职责”原则，也就是一个业务类，只有一个职责，具体到实现，就是一个业务类只有一个接口方法，当然此接口方法可以重载。

业务类是系统中最复杂的部分，也是系统的核心和最有价值的部分。根据实践，就算是“单一职责”，业务类的代码也是最多的。

3.5 实体工厂职责

实体工厂职责很简单，就是负责实体的创建、存储和销毁。实体工厂是与实体一一对应的，代码也是非常简单的。

4 结束语

本文提出的开发框架只是一个基础部分，更重要的是提出了一个设计模式，运用此设计模式能帮助软件工作者设计出好的软件结构。经过作者的实践，此模式能同时适应传统的C/S结构和当前流行的N层结构。对本文有任何看法者可通过.cn联系我们。

参考文献：

[1]Erich Gamma，Richard Helm，Ralph Johnson.设计模式[M].北京:机械工业出版社,2000.

[2]Martin Fowler.分析模式[M].北京:中国电力出版社,2003.

[3] Craig Larman.UML和模式应用[M].北京:机械工业出版社,2002.

本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。