摘要 通用报表系统设计运用模型-视图-控制器设计模式构造客户端报表视图与报表数据间的协作模型，将报表框架与报表数据分离，用户能根据处理需要自定义报表式样和指定数据源，系统自动生成所需要的报表。本文给出它们各自在报表系统设计中的应用范例。
关键字 报表系统；设计模式；数据异构；多窗口支持；模型-视图-控制器
1引言
传统报表系统，通常是针对某个商业领域使用，其使用的报表格式往往在设计时由设计人员已经定做成模版的形式存储在模版库中，用户使用时直接从模版库读取，处理方式也仅限于该领域内；虽然在一定程度上该解决方法带来了一定管理上的便宜，可对于现代企业用户来说，报表格式单一已经局限了报表只能作为记账簿来使用，使得报表的可塑性差，后期维护艰难，难以适应生产过程的多样性和变化性，无法满足大型企业不断扩充的适应性、智能型的要求，特别是当业务领域变化时，原有的报表系统往往很难支持新业务数据的管理分析，要进行大量的重新开发工作。
在本通用报表的设计中，将报表框架与报表数据分离开，用户即能根据自己的需要随意绘制表格，又能按照业务要求自主的选择数据来源。一旦框架和数据来源定义完毕，系统可以自动生成所需要的报表。为了经济的达到方便使用的目的，必须吸收先进的软件开发思想，采用优秀的软件开发方法以提高软件质量和软件的重用性，其中提高软件的重用性是减少开发成本的关键。www.lw881.com
本文主要介绍mvc设计模式在通用报表系统开发中的应用，给出了具体问题相应的解决办法，提高了软件的通用性和扩展性。
2 设计模式
设计模式是设计面向对象软件的过程中记录的知识和经验，用一系列类结构和对象来具体描述其含义。设计模式的目的就是复用这些面向对象设计的解决方案，根据具体应用完成具体的设计以及便于这些抽象解决方案的积累和交流。与不使用设计模式的软件系统相比，一个大量使用设计模式的软件系统的对象建模更加合理，对象间的耦合度更小，效率、可靠性、可升级性、并发性、平行性和分布性更高，更能获得高层次的设计复用和代码复用。
设计模式概念最先来自于城市建筑专家对建筑模式的定义“每一个模式描述了在人们周围不断反复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次的使用该方案而不必做重复劳动”。这种建筑上的模式思想在面向对象的设计模式中同样适用，模式的核心就在于提供了相关问题的解决方案。设计模式确定了所包含的类和实例，它们的角色、协作方式以及职责分配。它通过刻画部件静态和动态结构及其之间的合作关系，成功地应用于解决商业数据处理、电子通信、图形用户界面、数据库、分布式通信软件等软件构造中的问题。
一般而言，设计模式有4个要素：①模式名称：用来描述问题、解决方案和效果。②问题：描述可以在什么时候使用设计模式。③解决方案：描述了设计模式的组成部分，它们之间的相互关系及各自的职责和协作方式。④效果：描述了模式应用的效果及使用模式应该权衡的问题。一个设计模式命名抽象确定了一个通用设计结构的主要方面，这些设计结构能用来构造可重用的面向对象设计。
我们在报表系统中主要使用了模型-视图-控制器设计模式(mvc)、观察者（observer）、适配器模式（adapter）以及桥接(bridge)这几种设计模式。
3 设计模式的应用
3.1 模型-视图-控制器（mvc）
报表系统中为了方便用户对数据的分析和使用，同一业务数据常常需要多种视图呈现，即一个表格对象和一个柱状图对象可使用不同的表示形式描述同一个应用数据对象的消息。表格对象和柱状对象并不知道对方的存在，这样使用户可以根据需要单独复用表格或柱状图；当用户改变比表格中的信息时，柱状图能立即反映这一变化，这一行为意味着表格和柱状图都依赖于数据对象。早期的图形化程序设计常常围绕着事件驱动的用户界面来组织，这样的直接后果就是数据处理、程序功能与显示代码完全纠结在一起。大型的图形化程序中一个数据通常对应多种表示与处理方式，把特定界面绑定到应用程序上严重降低了程序的灵活性，使得一个很小的改动也牵扯到大量的代码，增加了程序开发与维护的工作量。20世纪70年代，mvc模式在small talk 80的gui设计中被提出，并且描述了不同部分的对象之间的通信方式，使它们不必卷入彼此的数据模型开发方法中，使程序结构变得清晰而灵活。
mvc模式包括三个部分：模型（model）、视图（view）和控制器（controller）,分别对应于内部数据、数据表示和输入输出控制部分。模型是与问题相关数据的逻辑抽象，代表对象的内在属性，是整个模型的核心。它采用面向对象的方法，将问题领域中的对象抽象为应用程序对象，在这些抽象的对象中封装了对象的属性和这些对象所隐含的逻辑。视图是模型的外在表现，一个模型可以对应一个或者多个视图，如图形用户界面视图、命令行视图、api视图；或按使用者分类：新用户视图、熟练用户视图等。视图具有与外界交互的功能，是应用系统与外界的接口：一方面它为外界提供输入手段，并触发应用逻辑运行；另一方面，它又将逻辑运行的结果以某种形式显示给外界。控制器是模型与视图的联系纽带，控制器提取通过视图传输进来的外部信息，并将用户与view的交互转换为基于应用程序行为的标准业务事件，再将标准业务事件解析为model应执行的动作（包括激活业务逻辑或改变model的状态）。同时，模型的更新与修改也将通过控制器来通知视图，从而保持各个视图与模型的一致性。
实现mvc模式时面对的主要问题是model和view的关系，在设计模式中的observer模式很好的描述了如何建立这种关系。这一模式中关键的对象是目标（subject）和观察者(observer)。一个目标可以有多个依赖它的观察者；一旦目标发生变化，所有依赖它的观察者都得到通知，并做出响应，即每个观察者都将查询目标进行更新，以保证和目标的状态同步。这种模式允许我们独立的改变目标和观察者；用户可以单独复用目标对象而无需同时复用其观察者，反之亦然。这种模式可以在不改动目标和其他观察者的前提下增加观察者。
在报表系统中，目标即为业务数据，观察者定义为在用户界面上的显示视图。显示视图是由其相关的业务数据决定，当业务数据发生变化时，视图也将发生变化。同一业务数据会有多种显示视图；相同类型的视图也可以表达不同的业务数据。而且可以根据需要在任意时刻增加和删除显示视图，大大提高了报表系统的通用性。
当报表系统业务数据变化时，它要通知依赖它的所有视图发生相应的变化，这样就需要在业务数据对象里记录依赖它的视图，或是增加一个关联查找机制。这两种方法在数据和视图间依赖关系比较少时可以高效的解决问题，但当它们之间的关系特别复杂时，我们就需要一个专门的对象来维护这些关系，这里我们称之为更改管理器（changemanager），它的目的是尽量减少视图反映数据变化所需的工作量。例如，如果一个操作涉及到对几个相互依赖的目标进行改动，就必须保证仅在所有的目标都已经更改完毕后，才一次性的通知它们的观察者，而不是每个目标都通知观察者。另外，观察者并不是对所有的事件都感兴趣，可以扩展目标的注册接口，让个观察者注册为仅对特定事件感兴趣，以提高更新的 效率。当一个事件发生时，目标仅通知那些已注册为对该事件感兴趣的观察者。
observer模式在报表系统中的层次结构如图1所示，其中dataentry为业务数据抽象，它的具体实现由concretedataentry来完成；userview是显示视图的抽象，具体使用的视图由concreteuserview实现；更改管理器（changemanage）的实现有两种：simplechangemanage和dagchangemanage ，它们分别管理单一目标的目标—观察者关系和多目标相互关联的目标—观察者关系。
图1 报表系统中observer模式层次结构图
其中业务数据的类定义如下：
class dataentry{
public :
virtual ~dataentry();
virtual void attach(userview *pview ); //增加视图
virtual void detach(userview *pview); //删除视图
virtual void notify(userview *psender); //通知
protected:
dataentry ();
private:
list<userview*> *userviewlist; //记录视图
}
显示视图的定义为：
class userview{
public:
dataentry getdataentry(); /*获取业务数据实体的状态，相当于模式中的getstate()和setstate()*/
virtual void notify (userview *pview);
virtual void ondraw(userview *pview);
//设计为虚函数以供重载
protected:
list<dataentry*> *dataentrylist;
//记录业务数据实体
}
在这里简要说明一下notify（）的实现：
void notify:: dataentry (userview *psender){
assert(psender==null||*userviewlist.isempty()); //判断视图列表是否为空
position pos = getfirstviewposition ();
while (pos! = null)
{userview* pview = getnextview (pos);
assert_vaild (pview);
if (pview != puserview)
pview->notity ();}
3.2 适配器模式（adapter）
在许多大型企业及某些行业的局域网或广域网内，由于历史和技术发展的原因存在着多种数据库同时在运行的情况，比如某大型企业、某地区的电力单位或电信公司等，可能正同时在使用着多种数据库（oracle, db2, sql server, sybase 或informix等）。在这样多的数据库并存的环境下，要求能任意访问到这些数据库，实现多种数据库间的数据转化、资源共享、数据一致性和完整性成为系统开发和应用中一个尤为突出的问题。
构建通用的数据库访问主要是实现对数据源访问的底层操作的封装，而仅仅给出数据读取对象或数据集对象等供商业逻辑层调用，因此采用adapter模式，根据不同的数据提供者产生相应的数据库连接、数据库命令等数据库对象来实现对低层操作的封装，通过暴露执行数据集对象等上层操作以供其他逻辑层调用。
对数据库的访问基础是基于结构化查询语言（sql），在具体对数据库的访问中，是通过sql语句来实现的。采用这种设计模式对数据库进行访问的方法是一种通用访问技术，即应用程序可用相同的源代码访问不同类型的数据库，如sybase, oracle等。
adapter模式是将一个类的接口转换成客户希望的另外一个借口。adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作，它又称为“wrapper”包装器。当要使用一个已经存在的类，而它的接口不符合需要，或是创建一个可以复用的类，该类可以与其它不相关的类或不可预见的类协同工作。
adapter模式的基本结构图如图2所示：
图2 adapter模式的基本结构图
adapter模式应用在报表系统中，模式中target即为应用程序中数据访问类，它负责进行数据库的连接、进行数据库操作等等；模式中的adaptee为实际存在的各种数据库；在进行系统实现时的主要工作是对不同的数据库编写相应的数据源驱动程序，即编写adapter。
应用程序对数据库的访问主要是选择一个数据源并连接它、提交sql语句以及检索结果，除此以外还可以确定并调整驱动程序的性能、浏览数据库编目等等；应用程序中数据访问类通过数据源驱动程序访问不同数据资源中的数据，每个不同的数据资源类型由一个数据源驱动程序支持。
数据源驱动程序是处理数据访问类对象的函数调用，提交sql请求到一个指定的数据元，并把结果返回到应用程序；如果有必要，数据源驱动程序修改一个应用程序请求，以使请求与相关的dbms支持的语法一致。每个驱动程序都针对特定的dbms；例如，一个oracle驱动程序不能直接访问informix dbms中的数据。数据源驱动程序展示基础dbms的能力，他们不能实现dbms不支持的能力。它进行数据源连接、检查应用程序中的函数错误、初始化事务和把sql语句提交给执行的数据源。数据源驱动程序必须把应用程序的 sql修改成针对相应dbms的sql，并把数据发送到数据源，或从数据源检索数据，包括根据应用程序的指定来转换数据类型，最后断开与数据源的连接。
当数据源驱动程序的数量增加，并且处理的事物逐渐复杂时，仅仅用应用程序的数据访问类来进行驱动程序的管理已大大增加了系统的负担，我们可以提供一个驱动程序管理器来管理数据源驱动程序。此时应用程序是被连接到驱动程序管理器，而不是驱动程序。它使用应用程序传递的连接句柄搜索目标驱动程序中的函数地址，并通过地址调用那个函数。驱动程序管理器多数只是把函数调用从应用程序传送给正确的驱动程序。驱动程序管理器最终的作用是加载和卸载数据源驱动程序，应用程序只加载和卸载驱动程序管理器。当它要使用一个特殊的驱动程序时，它调用驱动程序管理器中的连接函数，并指明一个特殊数据源或驱动程序名。使用该名称，驱动程序管理器为驱动程序文件名查询数据源信息，比如sqlsrvr.dll，然后它加载驱动程序，保存驱动程序中每个函数的地址，并调用驱动程序中的连接函数，然后初始化它自己，并连接到数据源。当应用程序使用驱动程序做完工作后，它调用驱动程序管理器中的sqldisconnect。驱动程序管理其中调用驱动程序中的此函数，断开与数据源的连接。然而，驱动程序管理器重新连接它时，把驱动程序保留在内存中。只有当应用程序释放驱动程序使用的连接，或者使用不同的驱动程序连接，并且没有器它连接使用此驱动程序时，它才卸载驱动程序。
3.3 桥接模式(bridge)
bridge设计模式时对象结构模式的一种，它将抽象部分与实现部分分离，使它们能够独立实现。当在一个程序中，某一个抽象可以由很多实现方法的时候，我们通常是使用面向对象中继承的方法来实现并协调这些方法。但是这种继承机制有以下不足的地方，而使用bridge设计模式都能使这些不足得到很好地解决。
继承机制使客户代码在实现功能的时候涉及到特定的相应平台，与平台产生相关性，对代码的移植产生很大的困难，但是bridge设计模式将抽象和实现部分放在独立的不同层次的类结构中，将抽象中与系统平台相关部分分离开来，同时也降低了实现部分对编译的依赖性，当改变一个实现类时，并不需要重新编译抽象部分和它的客户程序。
我们的报表系统是一个通用系统，我们希望这个系统能够支持多窗口系统。虽然不同的窗口系统有不兼容的程序设计接口，但是所有的窗口系统总的来说还是在做同一件事情，我们可以对不同的窗口系统做一个统一的抽象，在对各窗口系统的实现做一些调整，使之符合公共接口。
我们首先定义一个windows抽象类，它封装了需要各窗口系统都要做的一些事情，并且能跨越不同的窗口系统实现。在这个抽象类提供了支持大多数窗口系统的方便接口，其具体的子类支持用户用到的不同种类的窗口，而对不同窗口系统的实现则由windowimp类层次隐藏。windowimp是一个封装了窗口系统相关代码的对象的抽象类，为了使报表系统运行于一个特定的窗口系统，我们用该子系统的一个windowimp子类设置window对象。这样，避免了对窗口系统的直接依赖，这样可以让windows类保持相对较小而且较稳定，同时还能方便的扩展实现层次结构以支持新的窗口系统。
window和windowimp层次结构之间的关系有下图所示，其中windows_x即为可以扩展的窗口系统接口。
图3 window和windowimp层次结构
4 结语
应用设计模式可以使看似复杂的系统设计和实现简单化，设计出来的系统具有灵活、健壮和可复用性强等特点，而且还可以方便开发人员的沟通和交流，保证软件开发文档的准确性和易读性，便于代码开发工作。在报表系统中引入设计模式，不仅加深了对面向对象思想的认识，而且使得系统的设计间接明了，提高了软件系统的可维护性和伸缩性。
文章就设计模式在通用报表系统中的使用进行了一定的研究和探讨。主要就通用报表系统中几个关键的通用问题给出了相关的设计模式解决方案。该通用报表的设计为解决集团性企业、政府统计的报表汇总分析、预算编制、合并报表的解决方案；它还可以引入到分销管理中，以承担drp系统中临时性、非结构化数据的统计任务；根据统计管理对象的不同，它还能成为网上人事统计、资产管理系统的二次开发平台。
参 考 文 献：
1. erich grama , richard helm, ralph johnson, et al. design patterns elements of reusable object-oriented software. reading (mass): addison wesley publishing co, 1994
2. bertrand meyer, object-oriented software construction (second edition), prentice-hall international, inc, 1999
3. vangalur s. alagar and rokia missaoui(eds): object-oriented technology for database and software systems, world scientific publishers, singapore, 1995
4. grady booch: object-orient analysis and design with application, second edition, benjamin/cummings, menlo park(calif.), 1994
5. peter coad. object-oriented patterns. communications of the acm, 35(9):152-159, september 1992.
6. 刘立志，孙莹，陈松乔.基于构件技术的报表系统的设计与实现.计算机应用研究，2003;9;88-90
7. 吴秀丽，孙树栋.基于设计模式的报表生成组件的设计与实现.计算机工程与应用，2004;16;113-115,118.
8. 任中方，张华.mvc模式研究的综述.计算机应用研究，2004;10;1-4
