UML软件工程组织

实战揭秘:开发.Net平台应用系统框架(1)
作者:孙亚民 本文选自:赛迪网 2002年10月28日

 


微软的.Net平台给应用程序开发提供了一个非常好的基础系统平台,但是,如何在这个系统平台上构建自己的应用系统,还需要我们针对应用系统的特点,构建自己的应用系统框架(Framework)。我们在应用.Net开发系统的过程中,结合多年的开发经验,也参考了J2EE的架构,设计了一套.Net下的应用系统框架,以及相应的中间件和开发工具,已经在多个项目中和软件产品中应用,取得了很好的效果。现在向代价介绍这个框架的整体解决方案,希望对您有所帮助。

我们知道,对于典型的三层应用系统来说,通常可以把系统分成以下三个层次:

· 数据库层

· 用户界面层

· 应用服务层

对于应用系统来说,在这三个层次中,系统的主要功能和业务逻辑在应用服务层进行处理,对于系统框架来说,主要处理的也是这个层次的架构。

对于应用服务层来说,在一个面向对象的系统中,以下几个方面的问题是必须要处理的:

· 数据的表示方式,也就是实体类的表示方式,以及同数据库的对应关系,即所谓的O-R Map的问题。

· 数据的存取方式,也就是实体类的持久化问题,通常采用数据库来永久存储数据实体,这就需要解决同数据库的交互问题。这个部分要完成的功能,就是将数据实体保存到数据库中,或者从数据库中读取数据实体。同这个部分相关的,就是对数据访问对象的使用。在框架中,我们对ADO.Net又做了一层封装,使其使用更加简便,同时也统一了对ADO.Net的使用方式。

· 业务逻辑的组织方式。在面向对象的系统中,业务逻辑是通过对象间的消息传递来实现的。在这个部分,为了保证逻辑处理的正确性和可靠性,还必须支持事务处理的能力。

· 业务服务的提供方式。为了保证系统的灵活性和封装性,系统必须有一个层来封装这些业务逻辑,向客户端提供服务,同时作为系统各个模块间功能调用的接口,保证系统的高内聚和低耦合性。这里的客户指的不是操作的用户,而是调用的界面、其他程序等。Web层(ASP.Net页面)通常只同这个部分交互,而不是直接调用业务逻辑层或者数据实体的功能。

为了能够很好的解决这些问题,我们设计了这个框架。在框架中,针对以上问题,我们将应用服务层又划分成五个层次:数据实体层、实体控制层、数据访问层、业务规则层和业务外观层。各个层次同上述问题的关系可以用表表示如下:


层次 问题
数据实体层 数据的表示方式
实体控制层 数据的存取方式
数据访问层 提供对数据库的访问,封装ADO.Net
业务规则层 业务逻辑的组织方式
业务外观层 业务服务的提供方式

整个系统的结构图如下:

图中的箭头表示使用关系

将系统划分成这么多层次,其好处是能够使得系统的架构更加清晰,这样每个层次完成的功能就比较单一,功能的代码有规律可循,也就意味着我们可以开发一些工具来生成这些代码,从而减少代码编写的工作量,使得开发人员可以将更多的精力放到业务逻辑的处理上。正是基于这个想法,我们同时开发了针对这个框架的开发工具,并在实际工作中减少很多代码的编写量,效果非常好。同时,为了应用服务层更好的工作,我们设计了一个支持这个框架的应用系统中间件。(现在,已经有多家其他公司在试用这个中间件系统。)

同J2EE的EntityBean不同的是,我们采用了数据实体和实体控制分开的设计方法,这样的做法会带来一定的好处。

下面我将各个部分的设计方案和策略详细介绍如下:

数据实体层

我们首先需要解决的是数据的表示方式的问题,也就是通常的O-R Map的问题。

O-R Map通常的做法是将程序中的类映射到数据库的一个或多个表,例如一个简单的Product类:

public class Product
{
string ProductID;
string ProductName;
float Account;
}


在数据库中可能对应了一张Product表:


字段名 数据类型
ProductID Varchar(40)
ProductName Varchar(50)
Account float

这是最通常的做法,但是,由这种方式会带来一些问题。首先就是数据实体在数据库和程序中的表现方式不一样,对于一些涉及到多个表的“粗粒度对象”,一个实体类可能会引用到多个其它实体类,也就是说会在涉及到对象粒度的建模方面带来一些问题;其次在同数据库交互时,也涉及到一个转换的问题,如果一个对象涉及到对多个表的操作,问题就更大;最后,当系统做查询操作,需要返回多个对象时,因为涉及到转换的问题,效率就比较低下,而如果采用直接返回数据集的方式,虽然能够提高效率,又会带来数据表达方式不一致的问题。



版权所有:UML软件工程组织