云淡风轻

对一名软件开发人员而言，计算机语言只是手段，开发平台是工具，而技术才是真正的实现。所以任何一位在软件开发领域奋斗的朋友，都应努力把握目前软件开发的主流技术与知识，才能在这个领域中立于不败之地。

多层模式（n tier）

　　从事过windows下mis程序开发的人，都很清楚c/s是怎样实现的，在此笔者并不是要抛弃两层模式，只是希望通过笔者的描述帮助大家建立概念及了解三层结构带给我们的是什么空间。

误解一：c/s退出历史舞台了

　　笔者以为，c/s并没有到这么惨的地步，任何一个项目或任何一种方案，都要分析一下它实现的是什么东西，并且它将要面对的最终用户是什么性质。比如开发一个在windows下运行的程序，或开发一个在局域网内并且只针对少量用户的程序，或者一个管理程序、后台运行程序，未必一定强求使用多层模式，因为它并不能给你带来什么，反而会增加你的工作量与维护量。

　　我们不应该单纯追求技术的先进性，而要追求实用技术，当你要实现一个方案时，你要分析项目的性质及最终用户，然后再寻找能解决你问题的最实用手段。因为用户并不关心你采用多么先进的技术，用户关心的是可靠（reliable）、快速（rapid）、方便（convenient）。

误解二：多层模式只适用于大型项目

　　这是常见的一种误区，包括笔者自己，在进入n tier领域之前都是这种想法。但随着对n tier了解的不断深入，才发现这种理解是错误的。具体的选择应根据项目的特点及面向的最终用户群性质来决定。

　　如果你的项目运行在广域网，就必须考虑数据的安全以及带宽问题，或者当你面对的是普通用户，他们不可能完成复杂的程序设置、安装等工作，或者简单地讲，如果你要实现一种零成本或者最小成本的最终用户维护，你就必须考虑采用n tier的b/s模式来开发该系统。

　　我们习惯把n tier模式称作三层结构体系，因为n tier实际上是三层结构的变体。正确理解三层结构对于程序员而言非常重要，因为这里面包含着许许多多的理论和技术背景，融合了多少天才式人物的奋斗，才有了我们今天成熟的n tier开发基础。

三层结构的技术实现手段

　　要开发一个三层结构，这些技术是必不可少: 中间件、通信协议以及交易模式。

　　中间件 中间件是构造应用服务器不可缺少的。目前在window平台下通用的三层结构中间件有下面几种: midas、corba、com/dcom/com+以及asta。

　　midas是borland公司从delphi 3开始达到应用级的产品，功能强大，也是borland公司的旗艇产品，可应用在windows及linux下; corba是omg（对象管理组织）推出的产品，有强大的跨平台能力; com/com+是microsoft的拳头产品，也是每次microsoft都要宣传的理念之一，目前已整合到操作系统中。它的结构非常庞大，如果把midas比喻成一只野马，那com+就像是一头狮子。狮子看起来比野马强壮很多，但要驯服它却很不容易。最后一个是asta中间件，可能大家不太熟悉，实际上从1997年开始asta公司就致力于发展这个产品。它内嵌了socket连接，有强大的“消息”开发机制。

　　通信协议（或连接方式） 通用的中间件连接模式有tcp/ip（如socket）、dcom、corba等。程序员经常会把dcom与com混淆，实际是有区别的，com只是一种服务提供，而dcom才能使com真正发挥它的魅力，dcom在com的基础上增加了分布的概念。目前，微软又新推出了.net，对dcom进行了发展和完善。

　　midas既可使用dcom连接，也可使用socket连接，borland公司在delphi 5中对midas进行了核心性的改造，所以要使用midas，一定要看delphi 5以上版本的书籍。

　　com/com+只能使用dcom连接，corba使用自己的连接协议。这里笔者还想提一下dcom，dcom连接虽然优点很多，但设置过于复杂，所以连microsoft也承认其缺陷。microsoft在.net平台中将首推soap连接协议，soap是建立在http上层的协议，主要为了适应xml的发展，目前已得到许多大公司的支持（如ibm、oracle等）。

　　交易模式 最著名的是mts，它的英文全称是microsoft transaction server，交易模式实现的功能非常多，比如，多段提交模式，其pooling技术，也就是缓冲池技术，让数据提交更加安全、快速。很难想像，如果没有交易模式，三层结构要做什么：你要自己动手写大量的代码实现事务机制，如果解决得不好，还降低了程序的可靠性与速度。而mts是建立在系统层的，可以帮助你解决许多本应在程序里解决的东西。还有一点要记住，目前市面上windows开发平台上，只有delphi与vc才能真正发挥mts的功能。


三层结构编程要点
　　对此笔者不想讲太多理论，只给大家一句经典名言，这句话每个程序员都应该牢牢记住：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、技术，都是在弥补http协议存在的无状态缺陷，但即使有了这些工具，仍会觉得网页编程无法随心所欲，因为这些技术再先进，也无法解决http协议基于stateless的事实。

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

　　这里还要提一下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，若论工作机会多还数迷。最近又流行web services，也一定要弄明白，但要真正理解web服务，掌握xml是前提。头儿有一天谈到uml，也要补上……“可怜的程序员，何时是尽头！”

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