C/S、B/S及三层结构

 C/S、B/S及三层结构By  rk999888 发表于 2006-6-17 17:46:07 
B/S结构跟C/S结构的区别所谓B/S结构，就是只安装维护一个服务器（Server），而客户端采用浏览器（Browse）运行软件，即浏览器/服务器结构。

　　B/S结构的优点是维护方便，能够降低总体拥有成本。客户端运行软件，就像我们平时上网浏览网页一样，有个浏览器（通常是IE5.0）就行了，不用安
装其它软件。而且通过电话线也可以运行软件。B/S结构的软件所有的维护、升级工作都只在服务器上进行，而客户端就能获得最新版本的软件。

　　相对于C/S结构，尽管C/S结构相对于更早的文件服务器来说，有了很大的进步，但与B/S相比，缺点和不足是很明显的。

　　首先，B/S比C/S的维护工作量大大减少了。C/S结构的每一个客户端都必须安装和配置软件。假如一个企业共有50个客户站点使用一套C/S结构的
软件，则当这套软件进行了哪怕很微小的改动后（比如增加某个功能），系统维护员都必须进行这样的维护；将服务器更新到最新版本；将客户端原有的软件卸载，
再安装新的版本，然后进行设置，最为可怕的是客户端的维护工作必须不折不扣的进行50次。若其中有部分客户端是在另外一个地方，则系统维护员还必须跑到该
地方再进行卸载、安装、设置的工作。 若某个客户端，忘记进行这样的维护，则该客户端将会碰到版本不一致的问题而无法工作。
而B/S结构，客户端不必安装及维护。如果我们将前面企业的C/S结构的软件换成B/S结构的，我们看看软件升级后，系统维护员如何维护：
系统维护员只要将服务器的软件升级到最新版本就行了。其他客户端，只要重新登录系统，使用的就已经是最新版本的软件了。

　　其次，B/S相对C/S能够降低总体拥有成本， C/S软件一般是采用两层结构的。而b/s采用的是三层结构。

两层结构中，客户端接受用户的请求，客户端向数据库服务提出请求，数据库服务将数据提交给客户端，客户端将数据进行计算（可能涉及到运算、汇总、统计等等）并将结果呈现给用户。

　　在三层结构中，客户端接受用户的请求，客户端向应用服务提出请求，应用服务从数据库服务中获得数据，应用服务将数据进行计算并将结果提交给客户端，客户端将结果呈现给用户。

　　这两种结构的不同点是，两层结构中客户端参与运算，而三层结构中客户端并不参与运算，只是简单的接收用户的请求，显示最后的结果。由于三层结构中的客户端并不需要参与计算，所以对客户端的计处算机电脑配置要求是比较低的。

　　另外，由于从应用服务到客户端只传递最终的结果，数据量较少，使用电话线也能够信任。而采用C/S两层结构，使用电话线作为传输线路可能因为速度太慢而不能够接受。

采用三层结构的b/s的配置可以是提高服务器的配置，降低客户端的配置。这样增加的只是一台服务器（应用服务和数据库服务可以放在同一台计算机电脑中）的价格，而降低的却是几十台客户端机器的价格。起到了降低总体拥有成本的作用

C/S、B/S及三层结构（下） 谢攀 (轉帖)


上一期，作者在本文上半部分介绍了对C/S结构、两层模式、三层模式的看法，以及实现三层模式的技术手段，接下来作者将探讨B/S结构
和三层模式的实现方法。


三层结构编程要点


对此笔者不想讲太多理论，只给大家一句经典名言，这句话每个程序员都应该牢牢记住：All business logic in the Middle Tier（所
有的商业逻辑处在中间层上）。如果不这样，你开发的三层结构程序就不专业，或者只是C/S模式的翻版产品。这句话虽然很简单，要达
到这一境界却需要大量的经验积累。


另一个要领是: 一定要尽量减少应用服务器与前台程序的数据传递量以及Round Trip。因为如果你的三层结构存在频繁的Round Trip，那
么你开发的应用服务器效率一定非常低下，当同时进入10个连接时，你就会发现应用服务器接近瘫痪。


在开发三层结构的系统时，应该养成一种好习惯，就是在系统分析或者设计报告中，较为详细地描述如何解决商业逻辑、如何有效降低数
据传递量，以及只使用必要的Round Trip。只有这样，别人才能与你一起探讨你的解决方案是否合理，是否有更有效的实现方式。同时，
经过不断归纳，提高自己的系统分析能力。


在开发大量用户连接的应用服务器时，多线程技术是必要的，否则当应用服务器在处理一个用户的请求时，另一用户只能等待，如果这种
等待的时间太长了，用户就会对软件失去信心。还有一个是分布式的概念，你可以根据商业逻辑来切分，开发并发布多个应用服务器解决
不同的商业逻辑；或者你可以将运行应用服务器的多个进程分布在不同的服务器中，并根据访问流程自动引导用户到合理的应用服务器
中。


正是因为三层结构比C/S复杂，所以你要成为三层结构的高手，一定要经过一段较长的时间和大量项目的锻练。但三层结构体现了一个开
发人员与系统人员的专业素质，因为它涉及太多东西: 技术工具的选型、模块化和组件化思想、前后台功能的分割等等。从真正意义上来
讲，只有三层结构的项目才能完整反映软件项目的每个过程。


B/S模式与发展


主流的软件架构B/S与N Tier模式都有一些缺点，所以现在出现了许多B－N Tier的系统，就是基于Web浏览器的多层结构开发模式，它吸
收了两者的优点。


我们知道单纯的B/S方式，虽然很令人兴奋，并且最终用户使用成本几乎为零，但它存在许多不足，它的功能较弱，无法非常容易地实现
你的理念。比如你要实现一种商业模型，你会发现实际上Web方式是不安全、不可靠的，比如，用户可通过页面回退或前进来改变你所有
希望的结果、报表制作能力不足等。


为什么Web会造成逻辑实现上的困难？因为它是基于Stateless（无状态）的。打个比方，Stateless就是这样一种情形：你与你的用户中
间有一道墙，你并不知道墙另一边的用户长得什么样子，甚至是男是女你都不知道，然后你通过墙上的一个小窗递给他一件礼物，至于礼
物最终的流向，你也一无所知，这就是Stateless。所有基于HTTP的东西都是Stateless的。而Socket的魅力就在于它是有状态的。


笔者以为现在发展起来的ASP、JSP、Java技术，都是在弥补HTTP协议存在的无状态缺陷，但即使有了这些工具，仍会觉得网页编程无法随
心所欲，因为这些技术再先进，也无法解决HTTP协议基于Stateless的事实。


也许有人会问，这些动态网页开发技术是如何在一定程度上避免了Stateless的弊端的？以基于IIS的ASP技术来说，它使用Session变量来
实现State。但是不管什么技术，最终都落在了COOKIE上，也就是使用COOKIE来保留客户端状态。


这里还要提一下Socket。Socket目前应用十分广泛，ICQ、QQ等即时通讯软件，还有许多网络工具，大都基于Socket，因为Socket协议是
有状态的，所以才能做到这一点。可以这么说，是Socket让网络生活更精彩！


目前基于Web的多层结构采用的底层技术主要有SOAP＋State类协议或者HTTP＋State类协议。这里有一个Delphi程序员的好消息，从
Delphi 6开始引入WebSnap包（一种Web Provider产品），它的设计者被Borland公司称为Borland历史上最伟大的工程师之一。它同时支
持HTTP与SOAP协议，也采用了一种类似Session变量的模式来实现有状态(State)。它可以说是目前市面上最强大的基于平台的
Browse/Server开发工具之一，其不足是它还不能称为完全的RAD工具，而且门槛较高。为什么不是ASP或者ASP.NET呢？笔者认为ASP不是
基于平台的，它是基于脚本语言的，它的运行效率不高，而且它的调试困难。在Delphi 7中还引入了IntraWeb控件包，笔者以为它是一种
真正意义上的网页RAD开发工具，与WebSnap配合更会如虎添翼。


Web Provider、逻辑组件、多线程处理、交易机制、消息流转等组合在一起是N Tier开发的最高境界，笔者以为是大型商业软件架构的首
选。笔者在前面很少提到消息机制，主要是怕大家混淆了概念，消息机制并不一定在所有的多层结构中都存在，而且，如果要实现消息机
制，必须寻找实现手段（比如使用Socket），否则，如果在程序中强制实施大量消息流转（比如使用定时器监控和消息数据表方式），无
论是效率还是实现的复杂性来讲都是要考虑的问题。


软件开发人员的选择


笔者愿意把软件设计看成音乐艺术，它有许多流派，也有主流，但并不意味着别的思想被彻底抛弃。比如单层结构或C/S方式，许多人仍
然在用，而且很擅长。笔者不鼓励读者抛弃这些传统的东西，笔者的意思是要扩大眼界，开放思想。而多层反映的是一种集成的思想，以
安全、高效、图形方式整合系统，以组件思想逐步构架整个公司的商业逻辑，并降低最终用户使用成本。其最核心的思想是集中，所有中
间层是集中的，可以在不同的服务器上运行不同的商业逻辑组件（比如.NET），但这个逻辑组件一定是提供给所有前端程序使用的。现在
许多企业都在走系统集中的道路，集中可以带来无限的好处，但没有软件平台的支撑，集中是非常肤浅的。我们追求的不单纯是机器的集
中，机器的集中会同时带来网络带宽的压力，只有应用集中了，才能最终达到合理配置资源的目的，这也是为什么我们要用多层体系、要
用分布式思想来构建企业应用的真正原因。


笔者以为，在软件开发的今天，作为一名专业人员，如果总在单层或C/S构架下，永远形成不了系统思想，只有多层体系才能真正体会软
件生命周期的理念，从需求分析形成商业逻辑到系统设计、数据库结构设计、组件化程序编写、测试、推广，一个好的N Tier系统一定要
踏实地做好各个阶段的工作。这不像程序语言的变化或者开发环境的简单变换，因为它是一种开发思想与开发模式的完全变革，所以它也
一定是一个过程，不可能要求自己在一两个月内就能真正体会并开始驾驭N Tier模式，但商业模式变了，开发思想也要变，你必须也只能
让自己去适应新的思想，才能成为一名更加专业的开发人员。一旦你进入了N Tier的殿堂，并熟练掌握了这种开发模式，就会发现你开始
逐渐形成了软件开发的系统思想，并且在这个领域上越走越在前面，开发也会越来越有激情。


编后语：可怜的程序员


“真累！”时常听到软件开发人员这么说。软件开发是一个高强度的工作，这是共识，无论对于体力还是脑力都是一个考验，因此不少程
序员常常自嘲为“吃青春饭”的人。本人此前也做过几年软件开发，我也深谙其中的辛苦。我知道，对于软件开发人员而言，赶工期、赶
进度、封闭开发、长时间的加班加点等很多人已经习以为常，不过和心理上承受的压力相比, 这点痛实在算不得什么，软件技术的更新日
新月异，要在这一行立足，就必须时刻追踪技术发展，不然掉队事小，掉饭碗事大。C/S模式刚刚掌握，又流行起B/S架构，对高深莫测的
J2EE、CORBA还是一知半解，.NET又接踵而至。掌握VB太基础，掌握Delphi也才刚刚跨入程序员大门。要想待遇高，那得掌握VC或者BC，
若论工作机会多还数Java迷。最近又流行Web Services，也一定要弄明白，但要真正理解Web服务，掌握XML是前提。头儿有一天谈到
UML，也要补上……“可怜的程序员，何时是尽头！”


作为程序员的你是否在工作中陷入过这个误区，也为此苦恼过？或许你已经走出了这个阴影，或许你对此能轻松对付，你是否愿意让大家
分享你的经验和观点，无论如何，如果你对这个话题感兴趣，欢迎你和大家一起来讨论。