第1章分层+分布——大型系统的开发策略.docVIP

第1章 分层+分布大型系统的开发策略 1.1 典型的三层结构 典型的结构是将分为层：表现层、中间业务层和数据层，如图.1所示。 图.1 应用系统的三层结构 在三层结构中，表现层从用户接受任务，然后将任务委托给中间业务层来办理，中间业务层再委托数据层来办理。每个逻辑层分别提供不同的服务表现层：提供传统的用户接口技术，如MS Windows。 中间业务层：中间业务层表现层。 数据层：数据访问将中间业务层的请求转化为数据兼容的语言，例如SQL。数据访问执行某些API（例如自然数据库接口、使用OLE/DB的ADO或ODBC驱动程序）的请求。服务是实际（物理）的数据库技术，例如Oracle或SQL Server。 很显然，每一层还可以继续细分。但是，大于三层的逻辑结构1.2 为什么要分层 我们去餐馆吃饭，首先看菜谱，然后叫来服务员，告诉他我们想要吃的菜肴。服务员记下来以后，便会马上去通知大厨师傅要烹制这些菜。大厨师傅收到通知后，马上起火烧菜。过了不久，服务员便把一道一道香喷喷的美味端到我们的桌位上。 同样地，当我们访问一个基于ASP.NET技术的网站的时候，首先打开的是一个aspx页面。这个aspx页面的代码程序会去调用中间业务层的相应操作，中间业务层又会调用数据层的相应函数来获取结果，最后逐层将结果返回到页面。 在这里，高度体现了面向对象思想的封装原则。在我们去餐馆吃饭的这个过程中，菜谱、服务员、大厨师傅，是封装程度极高的三个个体。同样，三层结构中的三个逻辑层表现层、中间业务层和数据层 便于维护 系统分层以后，如果某一层内部发生变化，并不会引起系统“牵一发而动全身”，维护只在局部范围内进行。 假设系统原来使用的是Access 2000数据库，由于用户对系统性能提出了更高的要求，需要将数据库从Access 2000升迁到MS SQL Server 2000。系统分层以后，由于将访问数据库的代码分离出来单独放在一个程序文件里，因此只需要集中修改这一个文件就可以了。 这正如来餐馆吃饭的人越来越多、要求也越来越高，但现在大厨师傅的手艺已满足不了食客们的要求，餐馆决定另聘请一位大厨师傅。这一变动不会牵连服务员的工作，而对食客，只会感觉菜肴的味道更好，等待时间更短。 如果系统没有分层，在一个网站中，访问数据库的程序代码散落在各个页面中，就像夜空中的星星一样繁多。当需要把原有的数据库Access 2000升迁到另外的数据库SQL Server 2000时，除了需要把数据导入到SQL Server中，还得修改相应的.aspx.vb（Visual Basic）或.aspx.cs（C#）程序文件。也就是说，需要把调用OleDbConnection的地方修改成SqlConnection，还要把调用OleDbAdapter的地方，修改成SqlAdapter。这对于一个只有两个程序文件的小网站，修改起来并不费劲。但是，如果对于一个大型的商业网站，访问数据库的页面有很多很多，一个页面一个页面地进行修改，难度可想而知。最难以忍受的是，对这种维护工作的投入，是没有任何价值的。 降低应用程序的开发难度 应用系统被分层以后，每层要做的事变得单一，逻辑也清晰、简洁，实现起来自然就简单了。这与解答数学难题一样，难题其实是由若干简单题复合而成的。解答时，将难题分解成多个简单题，难题就不难了。 适应在网络环境下分布 在网络环境下，往往需要把计算功能和负荷合理地分配到联网的各计算机上。 应用系统被分层以后，实现了“高内聚、低耦合”，按照组件化软件设计的思想，很容易将应用系统部署到网络上。一个没有分层的大型系统，要将其分布到网络上是根本不可能的。 1.3 两种分布模式 .3.1 客户机/服务器模式 客户机/服务器（Client/Server，C/S）是近年来TCP/IP网络中大多数应用所采用的分布模式。它的出现为信息处理提供了一个高效、经济而又应用灵活的体系结构。 在客户机/服务器系统中，将应用程序分为两大部分：一部分是由多个用户共享的功能和信息，这部分称为服务器部分；另一部分是为每个用户所专有的，称为客户机部分。 客户机部分执行前台应用，例如管理户用接口、采集数据、格式化数据库和报告请求等。服务器部分执行后台应用，例如管理共享外设、控制对共享数据的存取、接受并回答客户机请求等。因此，客户机/服务器模式是一种应用与数据的协同分布，如图1.2所示。 图.2 客户机/服务器模式 客户机/服务器模式的主要优点 模块化：客户机端和服务器端分离，有利于系统的模块化和系统应用的划分。 分布特性：客户机端和服务器端执行不同性质的任务，从而可以将系统应用分布于不同的计算机。 充分利用资源：在某个具体应用中，客户机和服务器的划分仅针对这个应用，对于其他应用，客户机和服务器