Microsoft AJAX Library + ADODB = ?

最近做了一个基于Web的纯桌面端数据库应用，非常轻量级的，在挑选库的时候最后还是选择了自己熟悉的Microsoft AJAX Library，而没有使用prototype、dojo、YUI之类的。一方面，是因为Microsoft AJAX Library比较贴近我熟悉的控件模型，另一方面要做的东西真的轻量级得只需要普通的控件，不需要拖放和效果，不需要封装新控件或widget。

过程

整个制作流程大概是这样的：

首先，我设计了一套CSS模板，使用Sharepoint Designer来做，配色方案是临摹着其他漂亮的table排版模板做的。在这个过程中，我真的觉得Sharepoint Designer非常好用，你需要做的仅仅是用XHTML将模板所需要用到的语义全部写好，然后开始在<style />内部加CSS，只要CSS技术过关，很快就能把整个页面格式化为你想要的效果，而Sharepoint Designer的IntelliSense则能够自动提醒你哪个class下面有哪个id或者有哪些element。在格式化好页面后，把CSS从<style />移动到独立的CSS文件，并添加对一些特定的浏览器的修正，那就搞定了。

接着，开始根据程序的需要，在XHTML上设计Page、Form等的一些常用结构，并且写了一些基本的函数来实现Page直接的导航，Form内的常见操作。我用的仅仅是函数，这些函数根据性质以类来聚集，但没有做一些代表实体的类（例如Page类），因为我相信这个东西足够简单，通过函数完成简单操作就行了，没必要将XHTML元素映射为类（控件）。在搞定了如此简单Page划分之后，Page之间就完全解耦了，然后我就可以独立设计每一个Page里面的逻辑，而Page之间的数据传递则通过切换Page的函数负责，这有点类似QueryString的做法。不过我这里Page的概念仅仅是一个<div class="page" />的元素，而传递的可以任意JavaScript对象。

数据库的操作，我反而没有做任何的封装，直接new ActiveX("ADODB.Connection")，然后就拿来用。很raw的形式，写起来的代码有点点像ASP的feel，不过ASP是直接输出XHTML，而我是构建DOM元素。实际上所有的CRUD操作都是以最直接的形式执行的，几乎不存在任何业务规则，所以也是直接把CRUD的操作封到函数里就行了。有趣的地方在于，Sharepoint Designer在一个对象赋值为ADODB.Connection后，竟然能在IntelliSense提示Open等方法，不知道这是对于ADODB等常用对象的支持，还是对于任何COM对象都提供支持。

最后需要做的，就是在XHTML上把整个界面填充完整，把函数钩上事件，这就完成了。没有任何数据控件，不曾用到ITemplate，用得最多的无非是TextBox和Button。

总结

即使完全不用于AJAX开发，甚至是没有服务器端的开发，Microsoft AJAX Library也是一个很好用的库。如果你习惯MS那套控件设计的思想与风格，那么Microsoft AJAX Library会显得很容易适应，不过前提是你已经有很好的JavaScript基础。

现在国外有一个争论，就是一个JavaScript的入门者是否可以使用库，还是说有能力自己写一个库的人才应该使用库。这个争论的来源，我觉得是因为现在的库还是太过像手脚架了，能够帮熟练的使用者提高开发效率，提高代码质量和软件健壮程度，然而对于入门者来说却会因为对基础问题的不理解或者理解偏差而到职他们在使用库的途中犯下更多的错误。

在这个问题上，我使用MFC时就有切身体会，我就觉得熟练使用Win32API的人使用MFC才能获得最大的便利，而入门者使用MFC则对着MSDN左翻右翻也不得要领。我不懂Win32API，曾经学过一点点MFC，站在VB Form或Win Form的角度来理解，总是觉得MFC设计很怪异，为什么如此多地方设计得如此命令式而不封装起来呢？在使用MFC过程中碰到自己无法解决的问题时就更麻烦了，然而懂Win32API和熟悉MFC的人却能很快告诉我——例如这是因为MFC自身的一个设计缺陷，或者是它迁就Win32API使用方法或风格的地方。

MFC就是一个如此的手脚架，让懂Win32API的人能够更高效地做一些事情，而不懂的人却无法得到抽象带来的便利，因为它并没有怎样抽象，只是将函数式API封装为对象。现在的多数JavaScript库也就是做到了这个程度，将最初的DHTML到如今标准化的DOM API进行封装，却没有太多的抽象，所以用起来还是要清楚它到底干了什么。这是因为遇到了问题有可能无法在高层解决，而必须回到低层解决。

回到争论上面来，我个人支持库的使用者必须有能力完全理解库这一立场。考虑一个不太了解JavaScript的ASP.NET开发者，他使用Microsoft AJAX Library，无论是使用XmlScript还是JavaScript，他的“活动范围”也就是sample的附近，一旦超出了这个范围，他就在“凭运气写代码”了，这时候代码质量可想而知。如果他开发出来的东西还有给其他开发者调用，那就更危险了。这种现象其实也普遍存在于ASP.NET的控件开发者中，对ASP.NET理解有限的开发人员制作出来的控件就有可能和给使用者带来麻烦。

至于什么时候能够有高度抽象的Web开发框架……想一想，MFC诞生于1992，而Win Form以来的.NET Framework诞生于2002，这估计要10年吧。或者乐观一点，VB Form的抽象也很好了，因此Win Form才那么多参考其设计，拿比较成熟的VB6来说吧，诞生于1998，也要6年。这样说来，可能也要到2012才会有高度抽象的Web开发框架出现。况且，抽象也依赖于硬件发展，当我们不再为“小小一段”ViewState占用多少流量与带宽而烦恼时，抽象才有可能实现。