三层体系结构与数据库编程.pdfVIP

三层体系结构与数据库编程 接要 本文主要介绍了基于三层体系结构的网络数据库设计，并结合面向对象，分布式数据 库开发等理论。全文围绕一个典型而简单的例子，通过VB 编程语言，从分析、建模、设计、 编码等各个角度对三层体系与数据库进行了全面而详细的阐述，文中提供了全部源代码。 关键词 三层体系 数据库 面向对象 分布式开发 1. 三层体系结构 我们经常会看到许多应聘者在简历上写着“精通数据库编程”的字样，也经常会在招聘 网站上看到软件公司的招聘要求中某一项为“精通数据库编程”。于是这些应聘者去这些软 件公司面试，于是我们看到了许多“精通”者落选的现象。 一些程序员在设计数据库应用时，通常会采用数据控件绑定的方法实现。用鼠标拉几个 控件，再用鼠标设置几个属性，连键盘都不用动，就完成了一个数据库应用的开发！当然， 这的确是一种快速的数据库应用开发方式，但快速并不意味着精通。 对于大型的数据库应用系统，或是拥有众多客户端的应用系统，我们需要另外一种“精 通”，这就是几乎每个程序员都听说过的“三层体系结构”。 1.1.传统的C/S 模式 在传统的数据库应用体系中，客户端与数据库完全分开，在客户端上运行了大部分服务， 如数据访问规则、业务规则、合法性校验等等。每一个客户端都存在数据引擎，并且每个客 户端与数据库服务器建立独立的数据库连接（DB Connection ）。 基于该种体系的数据库应用系统的优势：开发周期较短，能够适应大部分中小型数据库 应用系统的要求（当客户端数量少于50 时）。 但是，随着数据库应用的日渐发展、数据容量的不断增加、客户端数量的不断增加，该 种体系结构显示出了诸多缺陷，主要体现在以下几个方面： 1、 可扩充性：对于数据库服务器端，每当建立一个数据连接，就会占用大量的系 统资源，当数据连接达到一定数量（如20 个）时，数据库服务器的响应速度与 处理速度将大打折扣。 2 、 可维护性：基于传统C/S 的数据库应用系统，业务规则通常置于客户端应用程 序中。如果业务规则一旦发生变化（随便举个例子，如身份证号码有可能升为 19 位）时，我们就必须修改客户端应用程序，并且将每个客户端进行相应的升 级工作。 3、 可重用性：采用传统C/S 的设计模式时，数据库访问、业务规则等都固化在客 户端应用程序中。如果客户另外提出了B/S 的应用需求，则需要在 WEB 服务 器中重新进行数据库访问、业务规则、合法性校验等编码 （例如将数据库访问 写入ASP 代码），而所做的工作与客户端应用程序中的功能完全重复，从而加 大了工作量，又使得程序开发者心里感到极不舒服。 正因为以上的诸多缺陷，使得三层（多层）体系结构成为目前数据库应用开发的首选， 甚至客户有时也会提出该种技术需求。 1 1.2.三层体系结构 所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这 里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也 不仅仅有B/S 应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机 器上。 三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。 通常情况下，客户端不直接与数据库进行交互，而是通过 COM/DCOM 通讯与中间层建立 连接，再经由中间层与数据库进行交互。 这样的好处显而易见： 1、 由于数据访问是通过中间层进行的，因此客户端不再与数据库直接建立数据连 接。也就是说，建立在数据库服务器上的连接数量将大大减少。例如一个 500 个客户端的应用系统，500 个客户端分别与中间层服务器建立DCOM 连接，而 DCOM 通讯所占用的系统资源极为有限，并且是动态建立与释放连接，因此客 户端数量将不再受到限制。同时，中间层与数据库服务器之间的数据连接通过 “连接池”进行连接数量的控制，动态分配与释放数据连接，因此数据连接的