回归C/S?解释Bindows

没有看过《程序员》2004年第5期gigix的《王朝复辟还是浴火重生——The Return of Rich Client》，不过在博客堂看过Kaneboy的《Return of Rich Client 》，还有CSDN站点的《迎接Client/Server模式的回归 vibration（原作）》，MSDN站点也给出了一篇《Back to the Future with Smart Clients》

500) {this.width = 500; this.alt = '点击查看原图'; this.style.cursor = 'hand';}" border=0

Bindows界面演示图

在Browser/Server时代，最经典的Framework莫过于Erik等编写的Bindows，就我个人看来，这个框架已经将JavaScript的OOP和基于IE（6.0)的DHTML发挥到极点，所以Kaneboy认为配合Lostinet的Janc，基于xmlhttp的无刷新技术，能够开发非常强大的Web Application应用。我无意去否认Erik在Client Programing的功底，从某种意义来说，他恰恰是我在JScript编程上最最重要的导师，至于国内的.NET高手Lostinet，相信没有几个人会怀疑他的能力。

quote:

Written By Kaneboy

我个人认为这是一对非常好的伙伴，结合起来，可以完成我们想象不到的非常Cool的应用，JavaScript用于客户端界面的显示和处理，XMLHTTP用于客户端与服务器的信息传输。

JavaScript在客户端的表现力不容置疑，看看www.bindows.net所表示出来的能力，利用JavaScript几乎可以实现Windows应用程序所能干的大部分事情，而且Bindows提供了一个封装好的可以直接利用的JS类库，省了我们大把的力气。

XMLHTTP一直以来常被用于实现“无刷新”的Web页面，它和JavaScript配合，可以完成数据从服务器和客户端的传输。Janc是Lostinet实现的一套.NET类库，完整的封装了服务器端XMLHTTP接口，程序员不需要了解XMLHTTP的细节，就可以编写自己的XMLHTTP应用系统。（Lostinet好像在做Janc的下一个版本，叫做Rane）

想想，用Bindows构建客户端的显示界面，而与服务器的传输用Janc来实现，岂不是天作之合？Web系统原有的界面交互性差、页面刷新等问题都可以很好的解决。

任何事情都使用B/S是一件非常“愚蠢”的事情，在做企业开发的过程中，相信很多开发人员深受其害，为了所谓的“零部署”然后给企业用户吹嘘B/S如何如何，一无所知的客户到后来也就形成了一个错觉，所有都B/S，B/S是万金油，这样一来痛苦的还是开发人员，因此在CSDN的WEB版块总是有人问一些我们以为”愚蠢“却不得不面对的问题，比如无刷新，比如文本留痕，比如无提示关闭用户窗口等等，这样的问题不只一次的被问到，更加糟糕的是，即使你在这个版本解决了，在下一个浏览器的Update中，微软可能基于XX安全的原因，修复了一个”错误“，我们到头来被这些问题搞的晕头转向。

Bindows可以说解决了很多WEB开发人员需要解决的所谓UI问题，但是是否是Web开发人员最终的福音呢？在这里我似乎要对Erik说No了，使用过Bindows开发或者阅读过源代码的朋友应该都会很佩服，也认为做的太棒了，这点到现在我也不曾经怀疑过。不过欣赏归欣赏，Bindows具体真正的应用还是有很长的一段路需要走，也许也走不到那天，毕竟IE的开发计划已经停止，剩余的我们也只有等待Longhorn下面的Avalon带来的XAML。在Bindows 0.93发布的时候已经将IE内置的功能开发的淋漓尽致，包括Filter，包括xmlhttp，包括web service，包括vml，剩余所做的只是一些错误的修正及其代码的一些性能调整，但是IE本身的停止更新决定了Bindows不太可能有根本性的改变，因此，教学意义似乎更加重于商业意义，我不知道有多少的公司在做B/S应用的时候在WEB UI方面会真正的采用Bindows?

本质上来说，Bindows无法大量商业应用的主要原因在于效率还有平台的高度绑定要求（必须是IE6。0才支持全部功能），目前MB Technologies已经发布了Bindows 1.01，这个最新的版本似乎需要Money了，所以也无缘一见，我读过0.93这个版本大部分的源代码，因为也就以此版本为例，阐述几个我认为Bindows无法真正走入应用的理由。

1。JavaScript是采用Object-Based的方式实现对象的继承,任何Custom Class都可以指定prototype，也就是这个对象的原型实现，而且任何对象允许在运行时期修改prototype指向特定的对象实例。为了保持所谓的继承关系,大部分都是采用

code:

function BaseObject(){

//Base Object Implement

}

function SubObject(){

//Sub Object Implement

}

SubObject.prototype=new BaseObject();

这样的代码来实现对象继承的，而Object-Based的方式决定了每次有一个”子类“继承，都必须有一个预先的对象作为”子类“的prototype，虽然这个预先对象可以用无名对象和登记对象，但是无论如何，prototype指定的对象是必须存在的，因此JavaScript OOP编程中有点忌讳使用太深的对象继承树，因为为了维持这些对象关系的层次，我们不得不使用太多的对象。而Bindows恰恰如此，从下图我们可以看到为了实现一个ColorPicker，太多了如此多层的继承，那么初始化这个类库最起码的工作也需要创建5个对象，使这些父类的prototype不至于不知所从。

500) {this.width = 500; this.alt = '点击查看原图'; this.style.cursor = 'hand';}" border=0

分析Bindows Javascript库文件，这样的对象继承比比皆是，从某种意义来说就加大了不不必要的加载。

2。不知道Erik是基于怎样的考虑，包括在他原先的WebFx中的代码也有这样的问题，他喜欢那种一次全部载入的方式来实现脚本库，使用过Bindows都会发现，在窗口的加载期，总是需要一个漫长的等待过程，我这里说提的漫长是针对于其他本地文件而言，脚本的下载固然是一个方面，按照V0.93，脚本文件的大小是600多K,理论来说不应该那么慢，所以说根本原因在于加载的慢，在于那些继承对象的初始化，在一个普通的Web应用中，我们更多时候不会用到bindows的全部功能，因此一次全部加载更多的只是带来加载和执行速度的下降。这点Bindows根本没有遵循”用多少去多少“的原则，仿佛就是一个贪吃鬼，有多少就吃多少。最最致命的还不在于此，IE并不能够保证这些类库只被初始化一次，一个窗口初始化一次的问题也可能出现，这样可想而知，速度能够好到哪里去。

3。可能是基于类库完整的考虑的，Bindows封装了太多的本来属于HTML的方法，就相当于在标准的DHTML之外还做了一个完全的包装，就我个人看来这个带来的更多是坏处而不是好处。第一开发人员还必须完全理解bindows提供的api和dhtml模型如何对应，第二开发人员不得不面对一个完全新的API去开发他们的应用，何况这些方法和属性的封装更多的是在BiObject和BiComponent这两个基础类上的，因此任何实现对象比如BiWindow，BiChart都必须去经历那个创建过程，创建一个庞大的方法库的过程，而实际应用中这些方法根本不是开发人员能够用到的，一点一点的积累，这个将是一个灾难。

4。Java或者.Net中的Import,using等等语句不知道为何也不借鉴,还是刚才的毛病，那么多的Class我能够用到的有多少啊，比如我需要做一个基于menu的应用，将所有的chart的库文件全部加载何必呢，到0.93版本为止，我认为类库内部偶合太强，根本无法根据需求加载必要的模块。

5。内部大量利用了IE6.0的技术，虽然微软的浏览器已经一统天下，但是还没有达到完全使用IE6。0的地步，因此限制了Bindows作为Web UI应用框架的流行，在图表方面，大量采用了VML技术，但在我个人看来有点”炫耀“的感觉，我不曾怀疑作者的功底，但是在WEB上面的图形做到那样有点大可不比，何况在ie 5,ie 5.5这两个版本,VML引擎不是那么的成熟，很多地方的显示不够流畅和及其浪费资源，在目前企业用户的计算机里头，那样绚丽的图形最终会给用户带来崩溃。在小图形方面，偶尔采用VML是一个不错的选择，但是如果需要处理大量的矢量图形，SVG应该是一个更加明智的选择。

以上的5点是我个人认为目前的Bindows不够成熟或者无法改进的地方，也正是因为如此,everything都b/s是非常stupid的，而这几年网络的发展似乎让B/S似乎有点过了头，尽管ASP.NET中有了WebForm，Java中有JSF(Java Server Face)用来帮助WEB开发，但是WEB真的不是万能的，Microsoft也意识到了这点，所以Smart Client还有Whidbey中的ClickOne技术都正在表明，胖客户技术正在渐渐回归，不过和传统的C/S比较，应该是如gigix提到的”像凤凰一样浴火重生“。