Facade模式的软件N层架构的设计与实现

1 引言

软件架构(Architecture) 就是将整个系统分解为多个逻辑的包、子系统、层, 并制定它们之间的逻辑关系和物理分布关系。软件架构是软件设计中非常重要的一个环节, 在软件开发过程中, 当需求和架构确定之后, 整个软件就基本上可以定型了。软件架构是可以复用的开发方法, 能够提高整个软件系统的健壮性和性能, 能够帮助编码人员快速定位自己在项目开发中的角色和任务。

传统的客户机/服务器(C/S) 体系多为两层结构, 其伸缩性较差, 并且呈现逻辑与业务逻辑驻留在同一进程中, 二者难以分隔, 管理和维护困难。三层体系结构相对于两层结构有了一些改进, 它将呈现逻辑从业务逻辑中分离出来, 前者部署在客户PC机上, 后者放置在服务器端。客户端提出的服务请求通过中间的高速数据通道传送到服务端,
进而提交给数据库, 这种高速数据通道有效地降低了客户机与服务器以及客户机与数据库的连接数量。

N 层应用程序已经成为构建企业级软件的标准。N 层应用程序就是被分成多个独立的逻辑部分的应用程序。层次体系就是利用分层的方式来处理复杂的功能, 层次系统要求上层子系统可以使用下层子系统的功能, 而下层子系统不能够使用上层子系统的功能。一般下层每个程序接口执行当前的一个简单功能,
而上层通过调用不同的下层程序, 并按不同的顺序来执行这些下层程序, 层次体系就是以这种方式来完成多个复杂的业务功能的。

.Net 技术为N 层体系架构的实现提供了良好的技术基础。.Net Framework 是微软推出的一套下一代开发平台。基于开发人员的角度来说, 它是一个公共平台类库,
包含了近100 个命名空间(NameSpace) 的近5000 个类, 此外还包括一个公共语言运行库(CLR) 。只要符合.Net 公共运行规范(CLS) 的语言都可以使用它提供的强大的类库, 并编译为微软的中间语言(MSIL) , 在其他的应用中就可以当作一个组件来调用。这些组件同时享受公共运行库带来的一切好处, 例如垃圾自动回收(GC) 、实时编译( JIT) 、跨语言跨平台。

2 公交信息管理系统的设计与实现

2.1 使用Fa!ade 模式的标准5 层架构

天津公交信息系统是一套基于B/S 架构的网络数据库应用系统, 将典型公交行业从基层部门———车队的数据采集, 到高层决策部门———计划科的数据统计分析等一整套日常工作管理流程纳入整个信息化系统,
其核心功能包括: 车队经济计划及行车作业计划制定、车队日常运营数据记录、每天运营情况统计汇总、各类月报表统计分析等。

经过对需求的详细分析发现, 在该系统中, 一部分功能都是对系统中原始数据进行简单的录入、查询、修改及删除操作, 不需要经过任何处理, 如公司基础数据录入( 车辆基本信息、线路基本信息、人员基本信息等) 以及车队日常运营数据录入等功能。而另外一些功能, 比如行车作业计划制定、车队日常运营情况汇总、B 类收入计算等功能则需要对录入的原始数据进行较复杂的业务逻辑处理后再存入数据库或者返回至用户界面, 其具体实现过程中往往会涉及到许多不同功能的类和方法, 操作起来也比较复杂。

经过对系统需求的详细分析, 最终我们采用了一套基于Facade 门面模式的5 层软件架构, 从用户界面到数据库操作依次分为:Web 层、业务外观层、业务规则层、数据访问层、数据实体层。该架构的核心表现在采用了Facade 门面模式, 在这种设计模式下使得Web 层对所有业务逻辑( 包括业务规则以及数据访问) 的访问均通过业务外观层进行, 其核心Facade
类为表示层提供了一个单一而简单的接口。

在该设计下, 每一层在系统中作用描述如下:

(1) Web 层: 为客户端提供对应用程序的访问,主要负责页面的显示, 页面状态的控制以及页面上各种控件的事件处理程序。如Button 的click 事件;同时该层还负责页面用户输入信息的基本验证功能, 如判断日期格式是否合法等。具体实现时,Web层由ASP.NET
Web 窗体和代码隐藏文件组成。Web 窗体只是用HTML 提供用户操作, 而代码隐藏文件实现各种控件的事件处理。

(2) 业务外观层: 实现了整个系统的公共入口点, 为Facade 设计模式中的核心类。业务外观层作为隔离层, 它将用户界面与各种业务功能的具体实现隔离开来, 对后台所有业务逻辑包括对数据库的访问都要通过该层来调用。它为表示层提供了一个单一而简单的接口, 使Web 层开发人员可以专注于用户界面的开发。

(3) 业务规则层: 该层中实现了系统中各种具体的业务逻辑。例如收入分类算法, 计划制定算法等。

(4) 数据访问层: 使用ADO.Net 中相关类实现, 为业务规则层及业务外观层提供数据存取服务, 用于和SQL Server 进行交互, 解决了数据存取的问题。

(5) 数据实体层: 该层解决了业务数据的表现形式问题, 根据需求分析, 每个业务实体将模型化物理数据库中的特定信息, 用于在各层之间传递业务数据。

整个系统开发过程中, 利用以上架构很好的解决了相当一部分复杂功能的设计与实现问题, 例如对于服票科功能———“个人B 类收入计算”, 完成该功能需要依次进行以下处理:

(1) 查询出当天整个车队及个人的A 类收入;

(2) 查询出本月截止当天的参数余额累加值

(3) 根据当天整个车队的A 类收入、本月的计划参数以及截止本月当天的参数余额累加值计算出当天使用的实际参数;

(4) 根据参数类型以及参数值选择计算算法(不同的参数类型有不同的算法);

(5) 利用上一步选择的算法计算当天个人B类收入;

(6) 计算结果在页面显示同时存入数据库。

针对以上需求, 在5 层架构下, 负责Web 层开发的人员在设计好界面后, 只需在“计算”按钮的Click 事件中调用Facade 层提供的Compute()方法,就完成了所有的数据存取以及计算工作, 之后做的事情就只是将返回的结果显示出来; 而后台复杂的数据存取、算法选择、收入计算等功能就交给了精通需求的Facade 层的开发人员解决就可以了;
同样, Facade 层开发人员亦可以将需求分解成若干相互独立的数据存取或者处理过程, 并定义相关的接口交由精通ADO.Net 以及C#语言的Rule层及DataAccess层开发人员实现即可, 而后者则可以不去考虑需求, 只需针对Facade 开发人员定义的接口编程即可。如此一来, 在多人分层开发项目时, 便可以充分发挥精通不同技术的开发人员的特长,
极大的提高了开发效率。

2.2 对标准5 层架构的改进

在利用以上标准5 层架构进行系统功能实现时发现, 针对复杂功能, 例如上节提到的B 类收入计算, 使用该架构确实能够带来层次结构清晰的程序, 提高开发效率, 但是针对普通的原始数据的录入、修改、删除以及查询功能, 在使用以上架构时就显得有些过于庞杂, 不仅没有减少代码量, 还增加了开发难度。基于这种情况, 我们针对这些简单功能对以上标准的5 层架构进行了改进, 改进后的类

改进的核心突出表现在以下两点:

(1) 实体类的改进。

(2) 引入公共的CommonFacade 以及CommonAccess对象。

在以上两点改进中, 对实体类的改进是整个架构变化的核心, 具体的改进方法如下:

(1) 将普通增删改功能的实体类继承自ADO.Net 中的DataSet 对象;

(2) 每个实体类中均引入一个DataTable 属性,该DataTable 对象的每个列对应原先实体类中的每个属性;

(3) 将每个实体类对数据库基础表进行操作的Sql 语句作为实体类的属性存在。

这样做的好处表现在:

(1) 可以轻松处理用户提出的成批录入原始数据要求, 在这种情况下, 不需要为每一条原始数据创建一个实体类, 每一条原始数据对应的只是实体类中DataTable 中的一行, 方便进行管理;

(2) 利用DataSet 作为实体类的父类可以充分利用ADO.Net 中的SqlDataAdapter 类提供的强大的数据访问功能, 同时该类提供了一套类似实体关系映射的机制, 仅仅调用Update()方法, 就可以完成实体类对数据库的Insert、Update、Delete 操作;

(3) 使用DataSet 作为实体类的父类是实现CommonFacade、CommonAccess 类的基础。

3 结束语

通过以上设计上的两点改进, 整个系统结构变的更加清晰简单。所有普通的增删改操作, 通过CommonFacade 以及CommonAccess 类均可以方便实现; 而对于需要复杂业务逻辑处理的功能,则依然构建各自的Facade、Rule 及DataAccess 进行处理。

从整个项目的实际开发过程来看, 利用以上设计架构, 能够很好的提高多人分层开发的开发效率, 有效的减少了访问数据库的重复代码。同时对此类基于网络数据库应用的MIS 系统, 也提供了一个可复用的软件架构。