c-s、b-s及三层结构.htm

本书介绍了三层体系结构的基本概念及它的构造等。对于初学者很有帮助

      COM/COM+是Microsoft的拳头产品，也是每次Microsoft都要宣传的理念之一，目前已整合到操作系统中。它的结构非常庞大，如果把Midas比喻成一只野马，那COM+就像是一头狮子。狮子看起来比野马强壮很多，但要驯服它却很不容易。最后一个是Asta中间件，可能大家不太熟悉，实际上从1997年开始Asta公司就致力于发展这个产品。它内嵌了Socket连接，有强大的“消息”开发机制。 
      </P>
      <P>　　通信协议（或连接方式） 
      通用的中间件连接模式有TCP/IP（如Socket）、DCOM、CORBA等。程序员经常会把DCOM与COM混淆，实际是有区别的，COM只是一种服务提供，而DCOM才能使COM真正发挥它的魅力，DCOM在COM的基础上增加了分布的概念。目前，微软又新推出了.NET，对DCOM进行了发展和完善。 
      </P>
      <P>　　Midas既可使用DCOM连接，也可使用Socket连接，Borland公司在Delphi 
      5中对Midas进行了核心性的改造，所以要使用Midas，一定要看Delphi 5以上版本的书籍。 </P>
      <P>　　COM/COM+只能使用DCOM连接，CORBA使用自己的连接协议。这里笔者还想提一下DCOM，DCOM连接虽然优点很多，但设置过于复杂，所以连Microsoft也承认其缺陷。Microsoft在.NET平台中将首推SOAP连接协议，SOAP是建立在HTTP上层的协议，主要为了适应XML的发展，目前已得到许多大公司的支持（如IBM、Oracle等）。 
      </P>
      <P>　　交易模式 最著名的是MTS，它的英文全称是Microsoft Transaction 
      Server，交易模式实现的功能非常多，比如，多段提交模式，其Pooling技术，也就是缓冲池技术，让数据提交更加安全、快速。很难想像，如果没有交易模式，三层结构要做什么：你要自己动手写大量的代码实现事务机制，如果解决得不好，还降低了程序的可靠性与速度。而MTS是建立在系统层的，可以帮助你解决许多本应在程序里解决的东西。还有一点要记住，目前市面上Windows开发平台上，只有Delphi与VC才能真正发挥MTS的功能。<BR></P><FONT 
      color=#ff0000>三层结构编程要点 </FONT>
      <P>　　对此笔者不想讲太多理论，只给大家一句经典名言，这句话每个程序员都应该牢牢记住：All business logic in the 
      Middle 
      Tier（所有的商业逻辑处在中间层上）。如果不这样，你开发的三层结构程序就不专业，或者只是C/S模式的翻版产品。这句话虽然很简单，要达到这一境界却需要大量的经验积累。 
      </P>
      <P>　　另一个要领是: 一定要尽量减少应用服务器与前台程序的数据传递量以及Round Trip。因为如果你的三层结构存在频繁的Round 
      Trip，那么你开发的应用服务器效率一定非常低下，当同时进入10个连接时，你就会发现应用服务器接近瘫痪。 </P>
      <P>　　在开发三层结构的系统时，应该养成一种好习惯，就是在系统分析或者设计报告中，较为详细地描述如何解决商业逻辑、如何有效降低数据传递量，以及只使用必要的Round 
      Trip。只有这样，别人才能与你一起探讨你的解决方案是否合理，是否有更有效的实现方式。同时，经过不断归纳，提高自己的系统分析能力。 </P>
      <P>　　在开发大量用户连接的应用服务器时，多线程技术是必要的，否则当应用服务器在处理一个用户的请求时，另一用户只能等待，如果这种等待的时间太长了，用户就会对软件失去信心。还有一个是分布式的概念，你可以根据商业逻辑来切分，开发并发布多个应用服务器解决不同的商业逻辑；或者你可以将运行应用服务器的多个进程分布在不同的服务器中，并根据访问流程自动引导用户到合理的应用服务器中。 
      </P>
      <P>　　正是因为三层结构比C/S复杂，所以你要成为三层结构的高手，一定要经过一段较长的时间和大量项目的锻练。但三层结构体现了一个开发人员与系统人员的专业素质，因为它涉及太多东西: 
      技术工具的选型、模块化和组件化思想、前后台功能的分割等等。从真正意义上来讲，只有三层结构的项目才能完整反映软件项目的每个过程。 </P>
      <P><FONT color=#ff0000>B/S模式与发展</FONT></P>
      <P>　　主流的软件架构B/S与N Tier模式都有一些缺点，所以现在出现了许多B－N 
      Tier的系统，就是基于Web浏览器的多层结构开发模式，它吸收了两者的优点。 </P>
      <P>　　我们知道单纯的B/S方式，虽然很令人兴奋，并且最终用户使用成本几乎为零，但它存在许多不足，它的功能较弱，无法非常容易地实现你的理念。比如你要实现一种商业模型，你会发现实际上Web方式是不安全、不可靠的，比如，用户可通过页面回退或前进来改变你所有希望的结果、报表制作能力不足等。 
      </P>
      <P>　　为什么Web会造成逻辑实现上的困难？因为它是基于Stateless（无状态）的。打个比方，Stateless就是这样一种情形：你与你的用户中间有一道墙，你并不知道墙另一边的用户长得什么样子，甚至是男是女你都不知道，然后你通过墙上的一个小窗递给他一件礼物，至于礼物最终的流向，你也一无所知，这就是Stateless。所有基于HTTP的东西都是Stateless的。而Socket的魅力就在于它是有状态的。 
      </P>
      <P>　　笔者以为现在发展起来的ASP、JSP、Java技术，都是在弥补HTTP协议存在的无状态缺陷，但即使有了这些工具，仍会觉得网页编程无法随心所欲，因为这些技术再先进，也无法解决HTTP协议基于Stateless的事实。 
      </P>
      <P>　　也许有人会问，这些动态网页开发技术是如何在一定程度上避免了Stateless的弊端的？以基于IIS的ASP技术来说，它使用Session变量来实现State。但是不管什么技术，最终都落在了COOKIE上，也就是使用COOKIE来保留客户端状态。 
      </P>
      <P>　　这里还要提一下Socket。Socket目前应用十分广泛，ICQ、QQ等即时通讯软件，还有许多网络工具，大都基于Socket，因为Socket协议是有状态的，所以才能做到这一点。可以这么说，是Socket让网络生活更精彩！ 
      </P>
      <P>　　目前基于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配合更会如虎添翼。 </P>
      <P>　　Web Provider、逻辑组件、多线程处理、交易机制、消息流转等组合在一起是N 
      Tier开发的最高境界，笔者以为是大型商业软件架构的首选。笔者在前面很少提到消息机制，主要是怕大家混淆了概念，消息机制并不一定在所有的多层结构中都存在，而且，如果要实现消息机制，必须寻找实现手段（比如使用Socket），否则，如果在程序中强制实施大量消息流转（比如使用定时器监控和消息数据表方式），无论是效率还是实现的复杂性来讲都是要考虑的问题。 
      </P>
      <P><FONT color=#ff0000>软件开发人员的选择</FONT></P>
      <P>　　笔者愿意把软件设计看成音乐艺术，它有许多流派，也有主流，但并不意味着别的思想被彻底抛弃。比如单层结构或C/S方式，许多人仍然在用，而且很擅长。笔者不鼓励读者抛弃这些传统的东西，笔者的意思是要扩大眼界，开放思想。而多层反映的是一种集成的思想，以安全、高效、图形方式整合系统，以组件思想逐步构架整个公司的商业逻辑，并降低最终用户使用成本。其最核心的思想是集中，所有中间层是集中的，可以在不同的服务器上运行不同的商业逻辑组件（比如.NET），但这个逻辑组件一定是提供给所有前端程序使用的。现在许多企业都在走系统集中的道路，集中可以带来无限的好处，但没有软件平台的支撑，集中是非常肤浅的。我们追求的不单纯是机器的集中，机器的集中会同时带来网络带宽的压力，只有应用集中了，才能最终达到合理配置资源的目的，这也是为什么我们要用多层体系、要用分布式思想来构建企业应用的真正原因。 
      </P>
      <P>　　笔者以为，在软件开发的今天，作为一名专业人员，如果总在单层或C/S构架下，永远形成不了系统思想，只有多层体系才能真正体会软件生命周期的理念，从需求分析形成商业逻辑到系统设计、数据库结构设计、组件化程序编写、测试、推广，一个好的N 
      Tier系统一定要踏实地做好各个阶段的工作。这不像程序语言的变化或者开发环境的简单变换，因为它是一种开发思想与开发模式的完全变革，所以它也一定是一个过程，不可能要求自己在一两个月内就能真正体会并开始驾驭N 
      Tier模式，但商业模式变了，开发思想也要变，你必须也只能让自己去适应新的思想，才能成为一名更加专业的开发人员。一旦你进入了N 
      Tier的殿堂，并熟练掌握了这种开发模式，就会发现你开始逐渐形成了软件开发的系统思想，并且在这个领域上越走越在前面，开发也会越来越有激情。 </P>
      <P><FONT color=#ff0000>编后语：可怜的程序员</FONT></P>
      <P>　　“真累！”时常听到软件开发人员这么说。软件开发是一个高强度的工作，这是共识，无论对于体力还是脑力都是一个考验，因此不少程序员常常自嘲为“吃青春饭”的人。本人此前也做过几年软件开发，我也深谙其中的辛苦。我知道，对于软件开发人员而言，赶工期、赶进度、封闭开发、长时间的加班加点等很多人已经习以为常，不过和心理上承受的压力相比, 
      这点痛实在算不得什么，软件技术的更新日新月异，要在这一行立足，就必须时刻追踪技术发展，不然掉队事小，掉饭碗事大。C/S模式刚刚掌握，又流行起B/S架构，对高深莫测的J2EE、CORBA还是一知半解，.NET又接踵而至。掌握VB太基础，掌握Delphi也才刚刚跨入程序员大门。要想待遇高，那得掌握VC或者BC，若论工作机会多还数Java迷。最近又流行Web 
      Services，也一定要弄明白，但要真正理解Web服务，掌握XML是前提。头儿有一天谈到UML，也要补上……“可怜的程序员，何时是尽头！” 
</P>
      <P>　　作为程序员的你是否在工作中陷入过这个误区，也为此苦恼过？或许你已经走出了这个阴影，或许你对此能轻松对付，你是否愿意让大家分享你的经验和观点，无论如何，如果你对这个话题感兴趣，欢迎你和大家一起来讨论。</P></TD></TR>
  <TR>
    <TD height=20>
      <DIV align=right></DIV></TD></TR>
  <TR>
    <TD colSpan=2 height=2 vAlign=top>
      <DIV align=center>
      
      </DIV></TD></TR></TBODY></TABLE></BODY></HTML>

</body><!-- CoreMail Version 2.5 Copyright (c) 2002-2005 www.mailtech.cn -->