《MVC设计模式在通用报表系统中的应用》由会员分享，可在线阅读，更多相关《MVC设计模式在通用报表系统中的应用（6页珍藏版）》请在金锄头文库上搜索。
1、1MVC 设计模式在通用报表系统中的应用摘要 通用报表系统设计运用模型-视图-控制器设计模式构造客户端报表视图与报表数据间的协作模型，将报表框架与报表数据分离，用户能根据处理需要自定义报表式样和指定数据源，系统自动生成所需要的报表。本文给出它们各自在报表系统设计中的应用范例。关键字 报表系统；设计模式；数据异构；多窗口支持；模型-视图-控制器1 引言传统报表系统，通常是针对某个商业领域使用，其使用的报表格式往往在设计时由设计人员已经定做成模版的形式存储在模版库中，用户使用时直接从模版库读取，处理方式也仅限于该领域内；虽然在一定程度上该解决方法带来了一定管理上的便宜，可对于现代企业用户来说，报表
2、格式单一已经局限了报表只能作为记账簿来使用，使得报表的可塑性差，后期维护艰难，难以适应生产过程的多样性和变化性，无法满足大型企业不断扩充的适应性、智能型的要求，特别是当业务领域变化时，原有的报表系统往往很难支持新业务数据的管理分析，要进行大量的重新开发工作。在本通用报表的设计中，将报表框架与报表数据分离开，用户即能根据自己的需要随意绘制表格，又能按照业务要求自主的选择数据来源。一旦框架和数据来源定义完毕，系统可以自动生成所需要的报表。为了经济的达到方便使用的目的，必须吸收先进的软件开发思想，采用优秀的软件开发方法以提高软件质量和软件的重用性，其中提高软件的重用性是减少开发成本的关键。本文主要介
3、绍 MVC 设计模式在通用报表系统开发中的应用，给出了具体问题相2应的解决办法，提高了软件的通用性和扩展性。2 设计模式设计模式是设计面向对象软件的过程中记录的知识和经验，用一系列类结构和对象来具体描述其含义。设计模式的目的就是复用这些面向对象设计的解决方案，根据具体应用完成具体的设计以及便于这些抽象解决方案的积累和交流。与不使用设计模式的软件系统相比，一个大量使用设计模式的软件系统的对象建模更加合理，对象间的耦合度更小，效率、可靠性、可升级性、并发性、平行性和分布性更高，更能获得高层次的设计复用和代码复用。设计模式概念最先来自于城市建筑专家对建筑模式的定义“每一个模式描述了在人们周围不断反复
4、发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次的使用该方案而不必做重复劳动”。这种建筑上的模式思想在面向对象的设计模式中同样适用，模式的核心就在于提供了相关问题的解决方案。设计模式确定了所包含的类和实例，它们的角色、协作方式以及职责分配。它通过刻画部件静态和动态结构及其之间的合作关系，成功地应用于解决商业数据处理、电子通信、图形用户界面、数据库、分布式通信软件等软件构造中的问题。一般而言，设计模式有 4 个要素：模式名称：用来描述问题、解决方案和效果。问题：描述可以在什么时候使用设计模式。解决方案：描述了设计模式的组成部分，它们之间的相互关系及各自的职责和协作方式。效果：描述了
5、模式应用的效果及使用模式应该权衡的问题。一个设计模式命名抽象确定了一个通用设计结构的主要方面，这些设计结构能用来构造可重用的面向对象设计。我们在报表系统中主要使用了模型-视图-控制器设计模式(MVC)、观察者（Observer）、适配器模式（Adapter）以及桥接(Bridge)这几种设计模式。33 设计模式的应用3.1 模型-视图-控制器（MVC）报表系统中为了方便用户对数据的分析和使用，同一业务数据常常需要多种视图呈现，即一个表格对象和一个柱状图对象可使用不同的表示形式描述同一个应用数据对象的消息。表格对象和柱状对象并不知道对方的存在，这样使用户可以根据需要单独复用表格或柱状图；当用户改
6、变比表格中的信息时，柱状图能立即反映这一变化，这一行为意味着表格和柱状图都依赖于数据对象。早期的图形化程序设计常常围绕着事件驱动的用户界面来组织，这样的直接后果就是数据处理、程序功能与显示代码完全纠结在一起。大型的图形化程序中一个数据通常对应多种表示与处理方式，把特定界面绑定到应用程序上严重降低了程序的灵活性，使得一个很小的改动也牵扯到大量的代码，增加了程序开发与维护的工作量。20 世纪 70 年代，MVC 模式在 small talk 80 的 GUI 设计中被提出，并且描述了不同部分的对象之间的通信方式，使它们不必卷入彼此的数据模型开发方法中，使程序结构变得清晰而灵活。MVC 模式包括三个
7、部分：模型（Model）、视图（View）和控制器（Controller）,分别对应于内部数据、数据表示和输入输出控制部分。模型是与问题相关数据的逻辑抽象，代表对象的内在属性，是整个模型的核心。它采用面向对象的方法，将问题领域中的对象抽象为应用程序对象，在这些抽象的对象中封装了对象的属性和这些对象所隐含的逻辑。视图是模型的外在表现，一个模型可以对应一个或者多个视图，如图形用户界面视图、命令行视图、API 视图；或按使用者分类：新用户视图、熟练用户视图等。视图具有与外界交互的功能，是应用系统与外界的接口：一方面它为外界提供输入手段，并触发应用逻辑运行；另一方面，它又将逻辑运行的结果4以某种形式显
8、示给外界。控制器是模型与视图的联系纽带，控制器提取通过视图传输进来的外部信息，并将用户与 View 的交互转换为基于应用程序行为的标准业务事件，再将标准业务事件解析为 Model 应执行的动作（包括激活业务逻辑或改变 Model 的状态）。同时，模型的更新与修改也将通过控制器来通知视图，从而保持各个视图与模型的一致性。实现 MVC 模式时面对的主要问题是 Model 和 View 的关系，在设计模式中的Observer 模式很好的描述了如何建立这种关系。这一模式中关键的对象是目标（subject）和观察者(observer)。一个目标可以有多个依赖它的观察者；一旦目标发生变化，所有依赖它的观察
9、者都得到通知，并做出响应，即每个观察者都将查询目标进行更新，以保证和目标的状态同步。这种模式允许我们独立的改变目标和观察者；用户可以单独复用目标对象而无需同时复用其观察者，反之亦然。这种模式可以在不改动目标和其他观察者的前提下增加观察者。在报表系统中，目标即为业务数据，观察者定义为在用户界面上的显示视图。显示视图是由其相关的业务数据决定，当业务数据发生变化时，视图也将发生变化。同一业务数据会有多种显示视图；相同类型的视图也可以表达不同的业务数据。而且可以根据需要在任意时刻增加和删除显示视图，大大提高了报表系统的通用性。当报表系统业务数据变化时，它要通知依赖它的所有视图发生相应的变化，这样就需要
10、在业务数据对象里记录依赖它的视图，或是增加一个关联查找机制。这两种方法在数据和视图间依赖关系比较少时可以高效的解决问题，但当它们之间的关系特别复杂时，我们就需要一个专门的对象来维护这些关系，这里我们称之为更改管理器（ChangeManager），它的目的是尽量减少视图反映数据变化所需的工作量。例如，如果一个操作涉及到对几个相互依赖的目标进行改动，就必须保证仅5在所有的目标都已经更改完毕后，才一次性的通知它们的观察者，而不是每个目标都通知观察者。另外，观察者并不是对所有的事件都感兴趣，可以扩展目标的注册接口，让个观察者注册为仅对特定事件感兴趣，以提高更新的 效率。当一个事件发生时，目标仅通知那些
11、已注册为对该事件感兴趣的观察者。Observer 模式在报表系统中的层次结构如图 1 所示，其中 DataEntry 为业务数据抽象，它的具体实现由 ConcreteDataEntry 来完成；UserView 是显示视图的抽象，具体使用的视图由 ConcreteUserView 实现；更改管理器（ChangeManage）的实现有两种：SimpleChangeManage 和 DAGChangeManage ，它们分别管理单一目标的目标观察者关系和多目标相互关联的目标观察者关系。图 1 报表系统中 Observer 模式层次结构图其中业务数据的类定义如下：class DataEntry pu
12、blic : virtual DataEntry();virtual void Attach(UserView *pView ); /增加视图virtual void Detach(UserView *pView); /删除视图virtual void Notify(UserView *pSender); /通知 protected: DataEntry (); private: ListUserView* *UserViewList; /记录视图 显示视图的定义为：class UserView public:DataEntry getDataEntry(); /*获取业务数据实体的状态，相当
13、于模式中的 GetState()和 SetState()*/6virtual void Notify (UserView *pView); virtual void OnDraw(UserView *pView); /设计为虚函数以供重载protected: ListDataEntry* *DataEntryList; /记录业务数据实体在这里简要说明一下 Notify（）的实现：void Notify: DataEntry (UserView *pSender)ASSERT(pSender=NULL|*UserViewList.IsEmpty(); /判断视图列表是否为空POSITION p
14、os = 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 等）
15、。在这样多的数据库并存的环境下，要求能任意访问到这些数据库，实现多种数据库间的数据转化、资源共享、数据一致性和完整性成为系统开发和应用中一个尤为突出的问题。构建通用的数据库访问主要是实现对数据源访问的底层操作的封装，而仅仅给出数据读取对象或数据集对象等供商业逻辑层调用，因此采用 Adapter 模式，根据不同的数据提供者产生相应的数据库连接、数据库命令等数据库对象来实现对低层操作的封装，通过暴露执行数据集对象等上层操作以供其他逻辑层调用。对数据库的访问基础是基于结构化查询语言（SQL），在具体对数据库的访问中，是通过 SQL 语句来实现的。采用这种设计模式对数据库进行访问的方法是一种7通用访问
16、技术，即应用程序可用相同的源代码访问不同类型的数据库，如 Sybase, Oracle 等。Adapter 模式是将一个类的接口转换成客户希望的另外一个借口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作，它又称为“Wrapper”包装器。当要使用一个已经存在的类，而它的接口不符合需要，或是创建一个可以复用的类，该类可以与其它不相关的类或不可预见的类协同工作。Adapter 模式的基本结构图如图 2 所示：图 2 Adapter 模式的基本结构图Adapter 模式应用在报表系统中，模式中 Target 即为应用程序中数据访问类，它负责进行数据库的连接、进行数据库操作等等；模式中的 Adaptee 为实际存在的各种数据库；在进行系统实现时的主要工作是对不同的数据库编写相应的数据源驱动程序，即编写 Adapter。应用程序对数据库的访问主要是选择一个数据源并连接它、提交 SQL 语句以及检索结果，除此以外还可以确定并调整驱动程序的性能、浏览数据库编目等等；应用程序中数据访问类通过数据源驱动程序访问不同数据资源
