传统的二层C/S结构存在以下几个局限:1它是单一服务器且以局域网为中心的,所以难以扩展至大型企业广域网或Internet;2受限于供应商;3软、硬件的组合及集成能力有限;4难以管理大量的客户机。因此,三层C/S结构应运而生。

　　三层C/S结构是将应用功能分成表示层、功能层和数据层三部分。其解决方案是:对这三层进行明确分割,并在逻辑上使其独立。原来的数据层作为DBMS已经独立出来,所以关键是要将表示层和功能层分离成各自独立的程序,并且还要使这两层间的接口简洁明了。

　　将上述三层功能装载到硬件的方法基本上有三种(如图1所示)。其中表示层配置在客户机中,而数据层配置在服务器中。

　　一般情况是只将表示层配置在客户机中,如图1(1)或图1(2)所示。如果像图1(3)所示的那样连功能层也放在客户机中,与二层C/S结构相比,其程序的可维护性要好得多,但是 其他问题并未得到解决。客户机的负荷太重,其业务处理所需的数据要从服务器传给客户机,所以系统的性能容易变坏。

　　如果将功能层和数据层分别放在不同的服务器中(如图1(2)所示),则服务器和服务器之间也要进行数据传送。但是,由于在这种形态中三层是分别放在各自不同的硬件系统上 的,所以灵活性很高,能够适应客户机数目的增加和处理负荷的变动。例如,在追加新业务处理时,可以相应增加装载功能层的服务器。因此,系统规模越大这种形态的优点就越显著。

　　值得注意的是:三层C/S结构各层间的通信效率若不高,即使分配给各层的硬件能力很强,其作为整体来说也达不到所要求的性能。此外,设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构的关键问题。

　　二、三层C/S的功能

　　1. 表示层

　　表示层是应用的用户接口部分,它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据,显示应用输出的数据。为使用户能直观地进行操作,一般要使用图形用户接口(GUI),操作简单、易学易用。在变更用户接口时,只需改写显示控制和数据检查程序,而不影响其他两层。检查的内容也只限于数据的形式和值的范围,不包括有关业务本身的处理逻辑。

　　图形界面的结构是不固定的,这便于以后能灵活地进行变更。例如,在一个窗口中不是放入几个功能,而是按功能分割窗口,以便使每个窗口的功能简洁单纯。在这层的程序开发中主要是使用可视化编程工具。

　　2. 功能层

　　功能层相当于应用的本体,它是将具体的业务处理逻辑地编入程序中。例如,在制作订购合同的时要计算合同金额,按照定好的格式配置数据、打印订购合同,而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如,用户检索数据时,要设法将有关检索要求的信息一次传送给功能层(参见图2),而由功能层处理过的检索结果数据也一次传送给表示层。在应用设计中,一定要避免"进行一次业务处理,在表示层和功能层间进行多几次数据交换"的笨拙设计。

　　通常,在功能层中包含有:确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。这层的程序多半是用可视化编程工具开发的,也有使用COBOL和C语言的。

　　3. 数据层

　　数据层就是DBMS,负责管理对数据库数据的读写。DBMS必须能迅速执行大量数据的更新和检索。现在的主流是关系数据库管理系统(RDBMS)。因此,一般从功能层传送到数据层的要求大都使用SQL语言。

　　三、三层C/S结构的优点

　　1. 具有灵活的硬件系统构成

　　对于各个层可以选择与其处理负荷和处理特性相适应的硬件。这是一个与系统可缩放性直接相关的问题。例如,最初用一台Unix工作站作为服务器,将数据层和功能层都配置在这台服务器上。随着业务的发展,用户数和数据量逐渐增加,这时就可以将Unix工作站作为功能层的专用服务器,另外追加一台专用于数据层的服务器。若业务进一步扩大,用户数进一步增加,则可以继续增加功能层的服务器数目,用以分割数据库。清晰、合理地分割三层结构并使其独立,可以使系统构成的变更非常简单。因此,被分成三层的应用基本上不需要修正。

　　2. 提高程序的可维护性

　　三层C/S结构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言。

　　3. 利于变更和维护应用技术规范

　　因为是按层分割功能,所以各个程序的处理逻辑变得十分简单。

　　4. 进行严密的安全管理

　　越关键的应用,用户的识别和存取权限设定愈重要。在三层C/S结构中,识别用户的机构是按层来构筑的,对应用和数据的存取权限也可以按层进行设定。例如,即使外部的入侵者突破了表示层的安全防线,若在功能层中备有另外的安全机构,系统也可以阻止入侵者进入其他部分。　　

　　此外,系统管理简单,可支持异种数据库,有很高的可用性。

　　四、三层C/S应用的开发

　　三层C/S应用的开发必须遵从以下原则:保护已有投资;降低应用系统的风险; 满足当前的迫切需要;考虑未来的发展规划。

　　开发出的三层C/S应用系统必须是:功能丰富且具有高可用性;功能要能跨应用系统;系统要能跨平台运行。

　　美国BEA系统有限公司产品计划和战略副总裁Jeri Edwards女士,按下述三种三层C/S应用系统的典型开发类型,分别举例介绍了他们的开发目标、开发过程、开发成果及经验体会。新建应用系统类型(Greenfield),如英国劳工局的劳动力市场系统;提升已有系统性能类型(Turbocharger),如Apple公司的AppleOrder Global系统;综合集成已有系统类型(Integrator),如AT&T的Zenith应用系统。Jeri Edwards女士根据三层C/S应用系统的开发经验和教训,总结出了实现C/S应用系统的"黄金10原则" :

　　(1) 尽量简化项目,使项目易于管理。应尽快建起一个初始系统,并尽早投入运行。当项目规模较大时,可以将其分割成由更小开发组担负的子项目。

　　(2) 要把精力花在设计上。首先要彻底弄清"需求" ,然后建立一个原型,以便测试设计中的"薄弱"环节。后来增加的特性或部件要保证与系统结构兼容。

　　(3) 要奉行"拿来主义"。近来,可供选购的市售C/S产品很多,要坚持"能买就买,为我所用"的原则。必要时,买来后可对系统加以修改,其中既包括基础部件也包括应用。

　　(4) 严格遵守业界标准。

　　(5) 采用TP监控器或对象事务处理管理器 (Object Transaction Manager ,OTM)。

　　(6) 要循序渐进。及时得到用户的反馈;保证项目各部分的良好衔接;及早解决接口问题,以保证项目进展协调;坚持"边分析,边设计;边编码,边测试"的原则。

　　(7) 在应用开发过程中,不可忽视系统管理。

　　(8) 反复测试,包括用户信任测试、基准测试、系统测试、性能测试、系统集成测试、坚固性测试、服务交付测试等。

　　(9) 制定合理的工程进度。

　　(10) 制定完善的系统拓展计划,包括用户的培训和技术支持、高效的硬软件装载、已有数据和系统的平滑迁移。

　　五、三层C/S应用中的核心

　　每个C/S环境,从最小的LAN环境到超级网络环境,都使用某种形式的中间件。实际上,无论客户机何时给服务器发送请求,也无论它何时应用存取数据库文件,都有某种形式的中间件传递C/S链路,用以消除通信协议、数据库查询语言、应用逻辑与操作系统之间潜在的不兼容问题。中间件是C/S环境中最重要的部件。所谓中间件是一个用API定义的软件层,是具有强大通信能力和良好可扩展性的分布式软件管理框架。它的功能是在客户机和服务器或者服务器和服务器之间传送高级通信,将客户机群和服务器群有机地"粘合"起来。其工作流程是:在客户机里的应用程序需要驻留网络上某个服务器的数据或服务时,搜索此数据的C/S应用程序需访问中间件系统,该系统将查找数据源或服务,并在发送应用程序请求后重新打包响应,将其传送回应用程序。

　　TP监控器在中间件技术中扮演着越来越重要的角色,特别是在三层C/S系统中。据Standish Group的调查,TP监控器是近两年信息业界最热门的技术之一。1996年有57%的关键应用是构筑在TP监控器上的。TP监控器擅长提供事务性语义,允许就环境速度和可靠性进行编程。作为一种中间件,TP监控器提供一种用于编写分布式应用程序的API,它通常包含一组强大的管理工具。TP监控器是一个高性能、高并行性、多用户的快速响应软件运行环境,它能有效地管理大量的并发任务,进而提高系统资源的利用率。如果采用TP监控器,系统总投资可节约30%以上,开发周期可缩短40%～50%。大多数投入应用的三层应用系统都配备有一套事务处理监控系统,BEA TUXEDO是目前应用最广泛的事务处理监控系统。

　　BEA TUXEDO是用于分布计算的中间件基础结构,它使开放式应用系统具有高可缩放性、高灵活性和高可维护性。它不仅具有分布式交易处理和应用间报文通信的功能,而且具有一系列极其完善的服务,可帮助企业建立和运行应用系统,使开发人员能够建立跨越多个平台、数据库和操作系统的应用程序。这样,可以灵活选配操作平台以充分适应应用环境。它具有以下特点:

　　1、支持多种软硬件平台。完全符合Open Group的X/Open标准,支持TCP/IP协议,支持包括Unix、Windows NT、AS/400和大型机专用系统在内的70多个硬件平台和操作系统。

　　2、结构开放、灵活。模块结构以高级程序接口ATMI(Application-to-Transaction Manager Interface)为中心,有丰富的ATMI函数可供调用。

　　3、开放的联机事务处理。可提供诸如事务性语义、透明的二段式提交、事务记录及分布事务处理管理结构等功能。

　　4、与DCE的结合。通过一套工具和程序库,实现了与Open Group组织的分布计算环境DCE的有机结合。

　　5、功能丰富,包括:应用管理;事件代理;通过鉴别服务、授权服务和数据加密服务,为客户提供安全保证;对COBOL语言的支持;应用动态调节、负载平衡等保证高可靠性的功能等。

　　六、三层C/S结构的应用现状

　　目前,用三层C/S结构开发的应用还不太多,但其数量的确在逐日增加。图3显示了北美运行的应用开发形态。三层C/S型应用的比例1995年占5%,1997年增加到7.8%,预计到1999年将占22.9%。二层C/S型应用和在原有系统上附加GUI型的应用,是被定位为向三层C/S型转化的过度形态。就当前来说,这种形态的比例要比三层C/S高,且要持续一段时间。那么,什么情况下应采用三层C/S呢?据Gartner Group的调查表明,具有下述特点的应 用应考虑采用三层C/S。

　　1、应用的服务或种类超过50个;

　　2、应用是用不同语言编写的;

　　3、两个以上的异构数据源,如2个不同的DBMS或1个DBMS和1个文件系统;

　　4、应用的生命周期超过3年;

　　5、高工作负荷,例如每天超过5万个事务处理或在同一系统访问同一数据库的并发用户数超过300个;

　　6、有至关重要的应用内部通信,包括像电子数据交换(EDI)这类企业的内部通信。

　　从传统的主机/终端型应用到三层C/S化,要考虑时间和费用问题,有的场合还不适合,需要循序渐进。

谈谈三层结构开发的理解

一、     前言
最近几个网友在讨论程序设计中的分层设计，反响非常激烈。大家对此非常感兴趣，且仁者见仁，智者见智。不管怎么样，他们的看法代表了他们对程序的理解，是他们实践经验的总结，是宝贵的。今天，这里我们且不评论他们的见解正确与否,这里我只谈谈我对分层的看法.希望能起到抛砖引玉的作用。
二、     三层架构开发简介
a)         什么是三层
首先，谈一下什么是三层架构，所谓的三层开发就是将整个业务应用划分为表示层－业务逻辑层―数据访问层－数据库等，有的还要细一些，明确地将客户端的表示层、业务逻辑访问、和数据访问及数据库访问划分出来，十分有利于系统的开发，维护、部署和扩展。
软件要分层，其实总结一句话，是为了实现“高内聚、低耦合”。采用“分而治之”的思想，把问题划分开来各个解决，易于控制，易于延展，易于分配资源。


                                    图1.三层结构示意图
表示层：负责直接跟用户进行交互，一般也就是指我们的前台，用于数据录入，数据显示等。它不应该做太多的工作。表示嘛，也就意味着只做与外观显示相关的工作。不属于他的工作他不用管也不该管。
业务逻辑层：用于做一些有效性验证的工作。以更好的保证程序运行的健壮性。如数据的有效性判断。不允许为的地方是否输入了空字符串，该输入Email的，格式是否正确等，数据类型的合法性判断，该是整型的地方当然不能接受字符串了，数据库操作是否合法，如字段长度的有效性判断。sql防注入的问题，用户的权限的合法性判断等，通过以上的诸多判断以决定是否将操作继续向后传递。尽量保证程序的正常运行
数据访问层：顾名思义，就是用于专门跟数据库进行交互。对数据的添加，删除，修改，显示等。需要强调的是所有的数据对象只在这一层被引用，如System.Data。SqlClient等，除数据层之外的任何地方都不应该出现这样的应用。
ASP.NET可以使用.NET平台快速方便的部署三层架构。ASP.NET革命性的变化是在网页中也使用基于事件的处理，可以指定处理的后台代码文件，可以使用C#,VB,J#作为后台代码的语言。.NET中可以方便的实现组件的装配，后台代码通过命名控件可以方便的使用自己定义的组件。显示层放在ASPX页面中，数据库操作和逻辑层用组件来实现，这样就很方便的实现了三层架构。
。
b)         为什么使用三层
那么我们为什么要使用分层开发呢，它有什么独特的优势呢？

     .NET开发平台为我们做开发提供了强大的技术支持，使我们的开发变得非常便捷，高效。通过code behind的强大支持，我们可以将页面设计和代码设计有效的分离，代码编写，页面设计同时进行。这比古老的asp那种插入式编写要迅速多了，Html归aspx，代码归aspx.cs，看起来倒也蛮清晰的，也没发现有什么不妥的地方
的确，光从功能实现的基础来说我们已经做得很好了，尤其对于一个简单的应用来说，代码量不是很多的情况下，这种一层结构开发完全够用了，没有必要搞得那么复杂。但是对一个复杂的大型系统来说这样的设计的缺陷就很严重了(下面会具体介绍，分层开发其实也是为大型系统服务的),。在开发过程中我们会不停把代码到处复制，以实现一些相似的功能。同样的代码为什么要写那么多次？不但使程序变得冗长，更不利于维护，一个小小的修改或许会波及很多页面。稍微不留神就会导致异常的产生。使程序不能正常运行。最主要的面向对象的思想没有得到丝毫的体现，打着面向对象的幌子却依然走着面向过程的老路。

     意识到这样的问题，我开始将程序中一些公用的处理程序写成公共方法封装在类中，供其它程序调用。象一些功能型的代码集合，数据库操作，如同SqlHelper那样对数据操作进行合理封装，把sql语句，参数列表作为参数，在数据库操作过程中，只要传入相应的参数就可以完成特定的数据操作，这就是我一开始的数据访问层，再不用每次操作数据库时都写那些重复性的数据库操作代码。在新的应用开发中，数据访问层可以直接拿来用。面向对象的三大特性之一的封装性在这里得到了很好的体现。似乎找到了面向对象的感觉，代码量较以前有了很大的减少，而且修改的时候也比较方便。这下应该可以了吧？

      试问一下，如果有一天数据库供应商发生了变化，因为数据量的增加，数据库有access变成了sql server？这下麻烦大了，原来的数据访问层失效了，数据操作对象发生了变化，且页面中涉及数据对象的地方也要进行修改，因为原来可能会使用OleDbDataReader对象将数据传递给显示页面，现在都得换成SqlDataReader对象，sql和access支持的数据类型也不一致，在显示数据时进行的数据转换可能也要进行修改。由sql向access的转换所做的修改会更多。还有一种情况，因为某种需要，我们要把Web形式的项目改造成windows应用，这时牵涉的修改有多大呢？如果在你的aspx.cs中放了很多处理代码，或者还有一部分代码存在于aspx中呢windows应用中可没有aspx阿，是不是整个系统需要重新来做了？这都是设计不合理惹的祸。再者，就是分布式的情况，现在的设计也无法做到。也就意味着，以上的设计充其量只能算小打小闹。
不知道我的解释是否让你体会了到了一些一层开发模式下的缺陷了呢？你是否碰到过这样的情况呢？幸运的是，多层开发架构的出现很有效的解决了这样的问题。通过将程序架构进行合理的分层，将极大的提高程序的通用性。

     三层中，各个层之间的分工是很明确的，面向对象吗，就像一个公司中的部门一样，每个部门的分工是不一样的，是哪个部门的任务就有哪个部门完成，对应的，各个部门的维护工作也有各自完成且不会影响其它的部门，至少影响不是很大，否则就只能说明分层还不合理。各个层之间通过有效的协作来完成系统的高效运行。表示层就是用来做接受/显示数据的工作，它要通过与其它层的协作来完成用户的请求，在这一层不该放太多的代码。逻辑层就是用来做数据有效性判断的，前面已经说过了，数据层就是用来完成底层数据交互的。表示层就不该去实现逻辑层的功能，当然我们会在客户端对用户的输入做一些判断，但服务器端，验证还要做。用户完全可以绕过客户端验证不是吗？现在我们在看上面说的问题，数据库发生了改变，我们只需要修改数据访问层，其它的地方我们都不用去管，这里我倾向于借助自定义数据实体来负责层与层之间的数据交互，我们把数据填充到自定义实体中，使用自定义实体的好处请参考我上面的两篇关于自定义实体的介绍的文章。通过数据访问层来完全封装数据供应商，使数据访问层对其它层完全透明，这样将数据库改变带来的修改完全限定在数据访问层内。我们可以借助一些模式来设计一个通用的数据访问层，这样即使数据库发生改变，我们只要修改一下配置就可以轻松搞定。对于开发平台的改变也变得很容易，不管是windows还是web，变化的只是界面而已，也就是所谓的表示层，它的内核没有变，相当于我们重作一个壳。表示层的代码是很少的，所以修改是很有限的，其它两层也不要修改就可以迅速做到web程序向windows程序的过渡。
你体会到三层的优势了吗？当然多层设计还有很多优秀的地方，我只是介绍了其中的一小部分。下面引入我所理解的三层的概念。
c)         我的三层结构。
那么怎么才能写出一个比较好的三层结构呢？下面说说我在程序设计中采用的做法，当然这里谈的只是我对三层的理解，不一定准确。欢迎拍砖。呵呵
        程序设计追求的是代码的通用性，可移植性，可维护性、功能扩展。怎么才能做到这些呢？这需要我们大量的实践经验做支撑。对面向对象思想的深入了解才能做到。个人觉得优秀的多层结构的设计肯定要先精通模式设计，不过遗憾的是对模式设计研究好长一段时间，依然没能领略到它的精髓，研究模式设计真的很过瘾哦。


以上是我在层序设计中所使用的分层示意图。
Web层：也就是表示层，它负责响应用户的请求，对于这一层越薄越好，一般不应该写太多代码，或者为了页面显示的需要做少量的代码。大量的处理工作都交给其它的层去完成。就好比传递员，只负责接受，并将请求向后传递，具体怎么做它不用管。

Common层：这里用来封装一些常用的功能性代码，主要用来为其它层服务的。还有存放一些自定义实体类型和自定义实体类型集合。用于各层次之间数据交互的载体。如User，UserCollection，关于自定义实体这里就不展开了，如果系统复杂的话这一层应该比较厚实，包括下面的BLL层也是如此。
BLL层：就是逻辑层，用来对数据进行有效性验证，牵涉到对敏感数据的操作都需要经过这里做判断，然后才能决定操作是否合法。

Dal层：数据访问层；封装对数据库的操作。我们可以做一个通用的数据访问层，下次开发的时候，就可以直接拿过来用。很爽的。有一点从这里传进来、传出去的数据都用自定义实体代替，这样就可以实现数据访问层对其它层的完全透明。这里封装所有于数据库相关的代码，包括sql语句，存储过程等。

分层的思路说完了，在多人开发系统的过程中，就可以按层来划分任务，只要设计的时候把接口定义好，开发人员就可以同时开发。而且不会发生冲突，做前台的人根本就不需要知道数据库结构是什么，该怎么去查找，更新，删除数据，他直观调用响应的方法就可以了。数据访问层的人也不需要知道前台发生了什么，定义好与其它层交互的接口，规定好参数就行。各个层都一样，做好自己的工作就可以了，只要能做到对其它层的完全透明。这样就可以将修改限定在一个比较小的范围内。

但各个层具体的代码该怎么组织，我想这就要看个人的造诣了，要开发出高性能，可扩展的代码就需要结合模式设计的思想，通过代码结构的科学、合理的设计方能在日后的维护过程中游刃有余。

三、     总结

1)       从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度

2)       三层架构可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。美国人曾利用分式计算解密，几个月就破解了据称永远都破不了的密码

3)       也是三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了