Net平台下通用数据库开发框架的研究

开篇：润墨网以专业的文秘视角，为您筛选了一篇Net平台下通用数据库开发框架的研究范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

[摘要]对于软件公司来说，建立起合适的快速开发框架是非常重要的，以自动化或者半自动化方式进行软件开发能大幅度提高软件开发的工作效率，使软件公司更快地适应不断变化的需求和业务的增长。研究和设计框架技术是当今一个非常活跃的研究领域。从底层开始构建应用程序是一件吃力不讨好的事情；没有框架的应用程序，很难想象会是一个完整、可用的应用程序。

[关键词].net；框架技术；N层架构

[作者简介]张翔，厦门大学软件学院硕士研究生，福建厦门361000；欧阳钟辉，厦门大学软件学院教授，泉州师范学院陈守仁工商信息学院教授，福建泉州362000

[中图分类号]F062.5　[文献标识码]A [文章编号]1672-2728(2008)12-0094-04

目前的开发方法与技术给了人们很多的自由，使得人们可以在此基础上开发出几乎所有的应用。但是当人们获得了自由，随之而来的就是复杂，并且还可能要失去面对变化的能力。.Net/Java与C/c++相比，让人们不用再理会复杂的内存管理等等底层的技术问题，更多的关注于所要解决的业务问题。但是人们在摆脱了内存管理后还是要关心对象的生命周期的管理。对象的持久化、对象的显示等等技术问题，它们并不是业务问题但却与业务逻辑纠缠在一起，想一想在开发软件的时候有多少时间是花在这些技术问题上的，或许人们的确需要牺牲某些自由来获得更多的方便。

一、开发框架的基本思想

框架(Framework)是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。另一种定义认为，框架是可被应用开发者定制的应用骨架。它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法。很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还在于框架内对象间的交互模式和控制流模式。

应用框架(Application Framework)的概念也很简单，它并不是包含构件应用程序的小片程序，而是实现了某应用领域通用完备功能(除去特殊应用的部分)的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类(该子类属于框架的默认行为)或组装对象来支持应用专用的行为。应用框架具有领域相关性，构件根据框架进行复合而生成可运行的系统。框架的粒度越大，其中包含的领域知识就更加完整。

二、为什么要进行框架开发

框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。由于框架能重用代码，因此从已有构件库中建立应用变得非常容易，因为构件都采用框架统一定义的接口，从而使构件间的通信简单。

框架能重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。这些标准接口使在已有的构件基础上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构架的设计。

框架还能重用分析。所有的人员若按照框架的思想来分析事务，那么就能将它划分为同样的构件，采用相似的解决方法，从而使采用同一框架的分析人员之间能进行沟通。

三、开发框架的设计

软件人员在做着表面上看似是对于各种不同应用的开发，其实背后所对应的架构设计都是相对稳定的。

(一)三层架构

所谓的三层开发就是将整个业务应用划分为表示层一业务层一数据访问层一数据库等。软件分层是为了实现“高内聚、低耦合”。采用“分而治之”的思想，把问题划分开来各个解决，易于控制，易于延展，易于分配资源。

(二)三层架构的优势

1　通过将整个系统分为不同的逻辑块，大大降低了应用系统开发和维护的成本；

2　将数据访问和逻辑操作都集中到组件中，增强了系统的复用性；

3　系统的扩展性大大增强。

(三)表示层的设计

表示层由UI(User Interface)和UI控制逻辑组成。

UI(User Interface)

UI是客户端的用户界面，负责从用户方接收命令、请求、数据，传递给业务层处理，然后将结果呈现出来。根据客户端的不同我们大体将应用程序分为BS(Browser―Server)浏览器结构，CS(C1i―ent―Server)桌面客户端结构。

BS的优点是无需操心客户端，只需要部署维护好服务器即可。cs的优点在于强大的界面交互表达能力。RIA(Rich Intemet Application)是为了融合这两种结构优点的一种技术，它依赖在客户端一次性安装一个通用解释器之后即获得强大的界面交互表达能力和无需部署具体客户端的方便性。

UI控制逻辑

UI控制逻辑负责处理UI和业务层之间的数据交互，UI之间状态流程的控制，同时负责简单的数据验证和格式化等功能。

下面分别讨论相关问题：

1　UI与业务实体之间的数据交互

此阶段负责数据交换的业务实体把它称为DTO(Data Transfer Object)，但需要说明的是这里的DTO并不是只包含数据的业务对象，它仍然包含必要的方法，是完整的业务实体。处理输入时从UI控件的获得数据填入DTO再向下传播，处理输出时用户发出请求业务层会将数据以DTO的形式返出再赋给UI控件展现。因此需要一种方式来自动解决这样的来回赋值问题。Java下Structs的Formbean对此问题提供了一定支持，而遗憾的是，Net下的不少控件虽然支持数据绑定但仍然没有一个现成完整的解决办法。

2　状态与流程的管理

复杂业务方面的状态与流程可以通过一些工作流引擎来解决，微软也了自己的工作流引擎。MVC(Model―View―Controller)模式提供了实现这一目标的方法。Controller是整个方案的核心，它是一个流程管理器，来自UI所有的命令与数据经过Controller分发给业务层或其他UI，这样可以把流程、权限等逻辑单独封装，例如配置到文件中，达到最大化的业务重用。.Net下MVC的方案并不像Java下有那么多选择，目前有以下几种选择：微软的UIPAB，它可以处理BS/CS下的流程跳转，可以使得相同的业务系统有WebForm和Win-Form不同的展现方式；开源的，它只适用于应用程序，它对流程、国际化、页面包装、XSLT页面转换提供了很好的支持；开源的Lattis，功能比较单一，同样只适用于应用

程序。

(四)业务层的设计

业务层封装了实际业务逻辑，包含数据验证、事物处理、权限处理等业务相关操作，是整个应用系统的核心。因此设计一个能够真实反映实际需要的业务层是非常必要的，可将实际业务具体分为业务数据与业务操作两部分。

1　业务数据

业务数据又是业务逻辑的核心，最终业务数据将以一种固定的格式表现于内存中，在系统的各个层次间传输，充当DTO角色。表达业务数据的方式一般分为两种Table Model和Domain Model。

Table Model是将数据库中的表直接映射成为业务数据对象，这样的优点是适合于机器操作，直接提供了这种操作的便利，但对于复杂业务关系的表达就很不直观。只适合于业务需求与数据表对应关系很直接的需要快速开发的情况。通常选用Dataset或者强类型Dataset(StrongTyped Dataset)，强类型Dataset支持编译时的类型检查，效率上要略高于普通Dataset。

Domam Modd则是根据实际业务按照现实方式用00思想建模，这样很适合业务复杂的系统。通常采用自定义数据实体(Custom Data Entity)方式表达。自定义数据实体，有着良好的性能，编译时的类型检查、数据表现方式非常直观符合实际业务的操作方式等优点，但需要自己定义维护类，在分布式环境下需要自己编写序列化方法。

2　业务操作

业务操作负责对业务数据进行各种业务相关的处理，例如验证，流向，整合，事物，权限等，但它不负责有关对数据源的操作。它与业务数据的关系设计有两种方式：

(1)分离业务数据与业务操作。将业务数据单独封装到只有数据get、set的数据类中，这个数据类只充当DTO。

(2)整合业务数据与业务操作。将业务数据与相关的业务操作封装在一起称为业务实体，业务实体作为统一的业务层为表示层提供服务，同时也负责作为DTO在各个层次间传输。这样完整的Domain Model设计方式，每个业务实体都可以作为一个单独组件形式存在，对于组件化复用有着莫大的好处。

(五)业务数据访问层的设计

业务数据访问层是一个针对具体应用系统的专属层，它为业务层提供与数据源交互的最小操作方式，仅仅是业务层需要的数据访问接口，业务层完全依赖业务数据访问层所提供的服务。这些服务负责从业务层接收数据或返回业务实体，它屏蔽了实际业务数据与机器存储方式的差别。业务数据访问层由DAO(Data Access Object)层和系统服务层两部分组成。DAO层为每个业务实体提供最基本的数据访问服务，系统服务层为系统全局提供与业务关系不大的通用数据访问服务，这两层处于系统中的同一个层次位置。

(六)数据层的设计

数据层的宗旨就是为数据源提供一个可供外界访问的接口，应该选用一种能够提供数据源无关的抽象数据访问接口并通过在其下挂接各种不同的DataProviador来访问数据源的数据层组件。这样的数据层有以下3种方案：

1　封装：这些数据访问组件都是基于的浅封装，它的优点在于封装层次低所以速度最快，人们可以手动组织sql语句用来适应复杂的操作以及个性的优化等。缺点是无法直接处理自定义数据实体方式的业务实体对象，需要将业务实体中的数据属性以参数形式传人传出。

2　OR―Maping组件：ORM是最好的数据持久解决方案，它的优点在于能够以面向对象的方式操纵数据，因此可以直接处理自定义数据实体的业务对象，根本不用操心SQL语句以及底层存储方式，这样极大的简化的代码提高了开发效率，对于日后维护扩展都带来极大的便利。缺点在于屏蔽了底层，无法针对具体数据源做优化，而且对于复杂关联的SQL操作有些力不从心，同时性能也差一些但辅助以缓存情况会好很多，而在.Net下最大的问题就是没有一个成熟便宜的ORM产品供人们使用，全部都是beta版本和商业版本。这些版本或多或少都存在一些问题，以至于真正应用中需要经过仔细考察。例如NHibemate，，XPO，等等非常多。

3　DataMapper(SqlMapper)：SqlMapper为以上两种方式提供了一个折中的选择，它可以以面向对象的方式直接处理自定义数据实体的业务对象，同时可以根据与数据源与业务实体的映射关系执行手写的SQL语句，这样完全可以针对具体数据源做优化，对于复杂操作同样可以胜任。目前只有一个产品，它是一个JAVA移至的开源项目，已经比较成熟。

(七)框架间各层的依赖关系

在对各层的讨论之后来总结一下各层间的依赖关系。说到依赖就离不开复用这个词，复用对软件开发流程的几乎每个阶段都有着重要的意义。在设计阶段它代表着更清晰的设计，在开发阶段它代表着更高的工作效率和代码质量，在测试阶段它代表着更轻易地捕获BUG，在维护和再开发阶段它代表着更小的工作量，更好的复用需要设计更好的依赖关系。逻辑上，表示层与业务数据访问层都依赖于业务层，而业务层是相对独立的，这样设计的优点就是最大限度地减少了变动对整个系统所带来的影响。最坏的情况就是业务的改变，业务改变其他依赖业务层的地方必须改变，但像表示层与业务数据访问层等其他非业务方面的改动不会影响到其他地方。

四、结语

至此，整个架构方案的讨论已经完成，人们可以看到.Net下可供选择的解决方寨是很有限的，反看Java世界倒有多成熟可供利用的组件框架。不过.Net也正在走向成熟，人们需要时间等待。以上提供的方案仅代表了一种基本的思路，在具体环境中需要做具体调整。