爱心论坛互帮互助电脑应用 → 从两方面看AJAX与B/S

分享到:

  共有4884人关注过本帖树形打印复制链接

主题:从两方面看AJAX与B/S

帅哥哟,离线,有人找我吗?
小猴乖乖
  1楼 | QQ | 信息 | 搜索 | 邮箱 | 主页 | UC


加好友 发短信 等级:小飞侠 帖子:1750 精华:30 积分:16454 金钱:27454 金币:0 魅力:9296 威望:0 登陆:335 注册:2007/4/5 13:51:22 近访:2010/8/25 14:55:41 在线:在线0天0小时0分钟.
离升级差0天20小时0分钟.
目前等级0
从两方面看AJAX与B/S  发帖心情 Post By:2007/8/22 7:32:58 [只看该作者]

贴子已被锁定

  近来遇到了这样的一个应用场景,某企业多年以来一直使用PowerBuilder开发的系统,随着公司的发展,决定将老的信息系统由C/S转为流行的B/S架构,于是问题出现:原有系统有大量的数据录入、精确报表打印等功能,而且用户都已非常习惯这种操作,希望新系统能保留原有系统的这种使用方便的特性。

  我一听到这个问题就头痛了,PB有一大堆功能强大的控件,要搬到浏览器里,用网页来模拟实现,太困难了。

  1、B/S为何难于提供好的用户交互体验?

  这里头的最大问题有几个:

  (1)无状态的HTTP协议

  Windows窗体间可以通过内存直接交换信息,但作为B/S架构通讯基础协议的HTTP是无状态的。

  如果将浏览器看成是客人,Web Server看成是旅馆,在HTTP协议的管理之下,会出现这种情况:不管某客人来访多少次,Web Server都将其视为第一次的访客。这样一来,客人每次都得带齐身份证件供旅馆工作人员“验明正身”。

  HTTP协议的无状态,导致Web Server的“六亲不认”,这固然能增加Web Server的吞吐量,却给应用系统的开发带来了麻烦。因为应用系统中往往有许多业务处理流程,天生就是信息流转的,即原始数据从一端进去,从另一端出来时应该已经过某些处理,怎可想象整个业务流程中的信息会流失?于是,在HTTP各请求间共享信息就成了件麻烦事,这就是HTTP请求的“状态保持”问题。每个B/S系统都必须解决这个问题。微软想了一些“歪招”,比如充分利用HTML网页的中隐藏域,再在Web Server上做些手脚,于是ASP.NET拥有了一套在各个HTTP请求之间维持状态的技术:Session,Cookie,ViewState,Profile,Application。

  然而问题并没有完全解决。比如,C/S系统中常见的收集用户输入信息的对话框,主窗体与对话框之间有着信息的交换(又分为两种:模式的和非模式的,前者对话框不关掉,主窗体不能被激活),在B/S芄怪拢捎阡榔鞯拿扛銮肭笫嵌懒⒌模诹礁龆懒⒌匿榔鞔翱诩涫迪掷嗨朴谀J蕉曰翱蛘庵种苯拥男畔⒔换唬一拐娌恢栏迷跹伞?/P>

  AJAX使用以下这种的方法来“摸拟”出模式窗体:将主窗体与对话框“合二为一”,对话框在HTML中就是一个div元素,平时是隐藏的,需要时再显示它。微软的AJAX Control Toolkit中甚至为这一功能设计了一个控件。诸如此类的小伎俩,在B/S开发中不胜枚举。

  可以看到,许多在C/S轻而易举就可实现的功能,在B/S中要实现则大费周章。

  (2) 特殊的运行环境——浏览器

  B/S系统的前端运行环境是浏览器,这就带来了诸多的限制,不能干许多事,比如直接访问硬件(例如打印机),也无法充分利用硬件的资源。例如,现在的新电脑都是双核的,你能直接用JavaScript加HTML写出一个多线程程序以充分利用这两颗“奔腾的芯”?

  而C/S系统则直接运行在OS(操作系统)之上,可以调用OS提供的所有功能,这种限制就不存在了。

  (3)尴尬的Web客户端编程语言——JavaScript

  传统的C/S程序,可以使用为数众多的各种开发语言,尤其是象C++,Java,C#之类主流面向对象语言,功能强大,使用方便,各种开发工具齐备,已非常成熟。

  与此相反,B/S前端所使用最多的编程语言JavaScript,不仅不让人喜欢,甚至让许多程序员“恨之入骨”,将“用JavaScript编程”看成是件苦差事。

  让我们来看看JavaScript的两大硬伤。

  首先,缺乏清晰而统一的编程模型。

  JavaScript虽然名字中有一个Java,并采用了类似的语法,但与真正的Java并无关系。唉,她本身是一只丑小鸭,总想着攀上天鹅这门亲,却没想到别人并不买账。

  JavaScript用到了许多对象,但说它是面向对象的吧,又实在难以令人信服(面向对象编程的基本单元是类),比如它没有类似于C#等主流面向对象语言的关键字class,到处是一个个的函数,这就使所有的代码难于以类的方式清晰界定;同时,它又不是结构化的(结构化编程的基本单元是函数),因为浏览器在解析HTML文档时,是采用流式解读方式,从而导致一些JavaScript代码被放在函数之外,在解析HTML文档时直接执行,而另一部分放到函数中的代码,则多采用事件驱动的方式运行,这就带来了复杂的程序执行流程,远不如纯结构化编程中统一采用函数调用的编程方式简洁。


 回到顶部
帅哥哟,离线,有人找我吗?
小猴乖乖
  2楼 | QQ | 信息 | 搜索 | 邮箱 | 主页 | UC


加好友 发短信 等级:小飞侠 帖子:1750 精华:30 积分:16454 金钱:27454 金币:0 魅力:9296 威望:0 登陆:335 注册:2007/4/5 13:51:22 近访:2010/8/25 14:55:41 在线:在线0天0小时0分钟.
离升级差0天20小时0分钟.
目前等级0
  发帖心情 Post By:2007/8/22 7:33:24 [只看该作者]

这样看来,JavaScript兼具面向对象,结构化,非结构化三种编程方式的特点,但却弄得不伦不类,没有一个清晰而统一的编程模型,难于写出结构清晰易于维护的代码,反而带来了许多混乱。

  其次,JavaScript的另一硬伤是它的浏览器运行环境。

  由于历史的原因,不同的浏览器,甚至同一浏览器的不同版本,其编程模型都有或多或少的差别,因而不得不写代码检测浏览器类型,比如需要为IE写一套代码,又为FireFox写另一套。这实在是一件麻烦事。

  上述这些问题,几乎是B/S架构系统“与生俱来”的“缺陷”。先天不足后天补,人们想出了许多招数来解决这些问题。AJAX是众人看好的希望之星。

  2、希望之星——AJAX

  这些天来,我系统地了解了一下微软的AJAX框架。发现这一框架的复杂远远超过我原先的估计,微软设计AJAX框架的工程师们,将各项Web开发技术的潜力发掘得很深,在很大程度上弥补了前面提出的问题。

  (1)对JavaScript语言的扩充:

  微软通过提供封装好的AJAX Library,增强了JavaScript的面向对象特性,可以方便实现继承,定义接口,序列化对象,引发事件,反射类型等功能,虽然比真正的面向对象语言(比如Java/C#)还有差距,但能将“丑陋”的JavaScript打扮得可以见人,也算是功力不凡。

  (2)大幅度提升浏览器端代码的功能

  在AJAX Library支持之下,配合增强功能的JavaScript,在浏览器本身的支持之下,可以在浏览器中写JavaScript脚本,方便地向服务器发出异步请求,实现页面局部刷新,并可以直接调用Web Service。

  (3)引入基于组件的开发(CBD)方式

  基于组件的开发(CBD)早已是面向对象系统的主流开发方式,虽然现在SOA(基于服务的架构)炒作得热闹非凡,但要达到CBD那样的成熟程度,还需要时间。

  对于JavaScript而言,别说SOA,能实现CBD都很困难。

  为了实现CBD,微软给JavaScript“大补特补”,增强了许多特性,基于Microsoft AJAX Library,程序员可以开发三种类型的可复用组件:None_Visual Component(不可视的组件,相当于面向对象系统中的一些提供公用功能的类)、Behavior(行为,扩充现有Web控件的功能)、Control(拥有可视化界面元素的Web控件)。

  尤其是AJAX Control ToolKit中提供的几十个控件,基本上实现了B/S对C/S用户界面大部分特性的摸拟,是这一新编程模型应用的典范。

  微软对JavaScript编程模型的增强,使软件工程师终于可以用CBD的开发方式开发Web客户端代码。我认为,这是一个进步。

  (4)增强的服务器端能力

  为了增强浏览器端代码的能力,必须通过服务器端予以配合。AJAX本身就基于Browser与Web Server相互支持的编程模型(Web Server提供数据服务,Browser提供XMLHttpRequest对象可向Web Server发出异步请求,当数据回来时,程序员可以用JavaScript编写代码实现对网页的动态局部更新)。

  通过AJAX Extension,微软增强了服务器端ASP.NET框架的功能。并将常用的功能外化为简单的Web控件,比如AJAX的核心控件ScriptManager,用于定义页面可更新区域的UpdatePanel,还有用于增强现有ASP.NET控件的位于AJAX Control Toolkit中的几十个Extender控件(即附加到现有控件上的控件,其目的是给现有控件扩充新的功能)。

  拥有了这些控件,开发Web前端程序就类似于在VB中设计窗体了。现在不仅仅是可以绘出类似于Windows窗体的界面,而且通过利用AJAX的异步请求与页面的局部刷新技术,在Web服务器的配合之下,可以在用户体验上逼进Windows窗体。

  不管多少人如何看不起VB,但VB所带来的可视化编程普及浪潮,的确影响深远,微软推动JavaScript编程走向这一步,也是大势所趋。为了提高Web 开发的效率,必须走这一步。

  然而,需要指出的是,不管后天如何“进补”,毕竟“先天不足”,B/S架构要在用户体验这点上超过C/S,还是非常困难。


 回到顶部
帅哥哟,离线,有人找我吗?
小猴乖乖
  3楼 | QQ | 信息 | 搜索 | 邮箱 | 主页 | UC


加好友 发短信 等级:小飞侠 帖子:1750 精华:30 积分:16454 金钱:27454 金币:0 魅力:9296 威望:0 登陆:335 注册:2007/4/5 13:51:22 近访:2010/8/25 14:55:41 在线:在线0天0小时0分钟.
离升级差0天20小时0分钟.
目前等级0
  发帖心情 Post By:2007/8/22 7:33:46 [只看该作者]

3、未来:B/S与C/S,谁主沉浮

  由于管理与部署的简便性,B/S架构成为当今许多信息系统的首选,然而,用户是追求好的使用体验的,大体总结起来,有以下要求:

  (1)漂亮的界面。这点B/S有优势。

  (2)方便的输入。比如许多用户都希望能不用鼠标就可以录入数据,或者是通过简单的点击实现数据的自动填充,在B/S架构下实现起来比较麻烦,AJAX可以在一定程度上解决这个问题。

  (3)闪电般的速度。对于C/S而言,要实现响应速度快,有许多的法子可想,可B/S就不容易了。由于受到浏览器的限制,客户端强大的硬件资源几乎是被闲置的。另外,网络速度是B/S架构的瓶颈,除非带宽能有快速的增长,否则,WWW就是World Wide Wait。

  C/S虽然拥有好的用户体验,但它的问题在于开发跨越整个互联网的分布式系统困难,而且由于需要安装客户端,系统更新与组件版本管理就成了一个大问题,此外,不象B/S架构中只需考虑服务器端的问题,在C/S架构由于多用户同时访问服务器,各组件间的调用和依赖关系复杂,在处理多线程访问共享资源,事务处理等方面必须同时考虑客户端与服务器端,吞吐量受到大的限制。因此,C/S多建构于局域网内,供企业内部使用。

  目前基本上是B/S与C/S共存,随着诸如AJAX之类B/S技术的广泛应用,B/S不断攻城掠地,占有上风,但不可能将C/S彻底地“打垮”。

  比较有意思的是:象微软这样的大公司,是如何看待B/S与C/S发展前途的?

  我等普通开发者,没有机会直接与微软高层对话,但可以从其公司的产品发展路线看出一些端倪:

  微软似乎并未认为B/S代表着未来的技术发展方向,相反,它的许多行动,都向着抛弃浏览器的方向在走。

  首先,微软简化了C/S的开发与部署问题,推出了Smart Client技术,让C/S客户端程序的更新可以无需人工干预,自动进行。

  其次,微软努力弥补B/S与C/S两者间的鸿沟,在设计ASP.NET时,毅然抛弃已取得不错业绩的ASP,直接采用类似于VB的“可视化控件+事件驱动” 编程方式,甚至将Web 页面也称为“Form”——Web Form。

  第三,微软可能认为AJAX是一种过渡性质的技术。

  微软在AJAX上迟迟不见动作,直到看到由于Google等公司成功应用AJAX技术提升Web用户体验而导致AJAX的迅速窜红时,才行动起来,给ASP.NET加上AJAX扩展,整个过程中显然行动并不积极,投入的资源也并不多,这与当年微软与网景公司展开浏览器大战时完全不一样。但从其在VS2008中将AJAX Extension内置为标准配置,并直接集成JavaScript的调试功能到IDE中,说明微软还是面对现实的,它承认AJAX拥有重要的地位与较大的发展潜力。

  其实,我分析微软的野心是“一统天下”,抛弃浏览器,彻底统一B/S与C/S。

  这点在.NET 3.0/3.5中看得很清楚。

  首先,微软用WCF统一了DCOM,.NET Remoting等主要用于C/S的技术,集成了原先位于COM+中的许多企业化开发特性,连同主要用于B/S架构的Web Service技术,统一地抽象并封装为可复用的WCF Service。很明显,微软要将信息系统开发模式由CBD转为SOA(即未来的系统是组装Service,而非组装Component)。

  其次,微软抛弃了非常成熟的Window桌面程序编程模型(Win32 API+消息/事件驱动)引入了一个全新的WPF编程框架,其中的一个重大的革新是符合XML规范的XAML(应用程序标记语言)的出现。XAML用XML格式纯文本文件来描述应用程序界面。

  我们可以很容易地将XAML与XHTML进行类比。浏览器解析XHTML代码,生成可视化的网页界面,而XAML则由.NET Framework 虚拟机负责解析,在Vista中,由于Vista直接集成.NET Framework 3.0,就可以将Vista看成是一个超级浏览器,由它负责读入XAML生成用户界面,并实现其所有应用程序功能。

  这样一来,一种新的编程模型浮出水面,不管是B/S还是C/S的系统,其方式都是统一的:读入XAML代码à解析à呈现à接收用户输入à处理数据à显示结果。


 回到顶部
帅哥哟,离线,有人找我吗?
小猴乖乖
  4楼 | QQ | 信息 | 搜索 | 邮箱 | 主页 | UC


加好友 发短信 等级:小飞侠 帖子:1750 精华:30 积分:16454 金钱:27454 金币:0 魅力:9296 威望:0 登陆:335 注册:2007/4/5 13:51:22 近访:2010/8/25 14:55:41 在线:在线0天0小时0分钟.
离升级差0天20小时0分钟.
目前等级0
  发帖心情 Post By:2007/8/22 7:34:09 [只看该作者]

在这个编程模型中,浏览器成了一个旁观者,不再是客户端应用的核心。

  新编程模型的运行平台是全功能的OS,而非功能受限的榔鳌U飧銮鹗蔷薮蟮模桓鲈诵杏贠S之上的浏览器,其功能怎能和OS自身相比!

  现在可以通过按面向对象方式组织起来的操作系统API(应用程序编程接口)方便地调用操作系统的各种功能,充分利用客户端的硬件资源(比如可以很容易地在.NET Framework之上开发多线程程序,“压榨”双核CPU的工作能力)。用户界面都用XAML来描述,这就统一了B/S与C/S的界面层技术。

  WPF最适合的运行环境是Vista操作系统,它的一个功能子集,现在称为Silverlight,被实现为一个浏览器插件,从而让WPF程序也能跑在传统的浏览器中。由于Silverlight和Vista本身都可以解析XAML,所以,现在可以用XAML只写一套界面代码,就同时适用于B/S与C/S,并获得相同的用户体验。

  由于B/S和AJAX存在着一些先天不足,如果将经过AJAX增强功能的B/S系统比喻为一个舞者,那么,这其实是一位带着镣铐跳舞的舞者,而微软公司的想法是,与其不断想法减轻这一镣铐的重量,为何不干脆直接抛弃这一镣铐呢?

  微软推出WPF与WCF,就是这样的一个尝试。

  应该来说,微软公司的这套发展战略是建立在对现有B/S与C/S各自的优缺点分析的基础之上而制订的,有它的科学性,也考虑到了自身的商业利益。但这一战略最终实现还有许多困难,因为即使强大如微软,也无法一统江湖。微软的对手与微软一样聪明,技术进步同样迅速。

  可以断言,由于信息系统应用的延续性,在相当长的一段时间内(也许有三五年,也可能有五到十年),B/S与C/S将同时并存,由于B/S许多突出的优良特性,在与C/S的竞争中将占上风,这个局面不会有大的改变。对于AJAX,作为B/S系统的一个重量级武器,虽然很有效,但存在不少缺陷,我对于它的未来发展,抱有谨慎的乐观态度,不过,作为一名Web 开发者,应该去了解并应用这一技术。

  未来的格局到底如何,某种技术到底有没有前途,都不是由个人说了算的。我想,B/S与C/S之争最终的格局,将是多方面因素共同博弈的结果。对于个人而言,必须与时俱进,及时调整自己的行动和战略,这是当代软件开发者的宿命。


 回到顶部