为了实现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、未来：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代码à解析à呈现à接收用户输入à处理数据à显示结果。
在这个编程模型中，浏览器成了一个旁观者，不再是客户端应用的核心。
新编程模型的运行平台是全功能的OS，而非功能受限的浏览器。这个区别是巨大的，一个运行于OS之上的浏览器，其功能怎能和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之争最终的格局，将是多方面因素共同博弈的结果。对于个人而言，必须与时俱进，及时调整自己的行动和战略，这是当代软件开发者的宿命。
