回归C/S--解释Bindows 选择自 liuruhong 的 Blog
http://dev.csdn.net/article/27/27574.shtm
没有看过《程序员》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》
Bindows界面演示图
在Browser/Server时代,最经典的Framework莫过于Erik等编写的Bindows,就我个人看来,这个框架已经将JavaScript的OOP和基于IE(6.0)的DHTML发挥到极点,所以Kaneboy认为配合Lostinet的Janc,基于xmlhttp的无刷新技术,能够开发非常强大的Web Application应用。我无意去否认Erik在Client Programing的功底,从某种意义来说,他恰恰是我在JScript编程上最最重要的导师,至于国内的.NET高手Lostinet,相信没有几个人会怀疑他的能力。
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指向特定的对象实例。为了保持所谓的继承关系,大部分都是采用
function BaseObject(){
//Base Object Implement
}
function SubObject(){
//Sub Object Implement
}
SubObject.prototype=new BaseObject();
这样的代码来实现对象继承的,而Object-Based的方式决定了每次有一个”子类“继承,都必须有一个预先的对象作为”子类“的prototype,虽然这个预先对象可以用无名对象和登记对象,但是无论如何,prototype指定的对象是必须存在的,因此JavaScript OOP编程中有点忌讳使用太深的对象继承树,因为为了维持这些对象关系的层次,我们不得不使用太多的对象。而Bindows恰恰如此,从下图我们可以看到为了实现一个ColorPicker,太多了如此多层的继承,那么初始化这个类库最起码的工作也需要创建5个对象,使这些父类的prototype不至于不知所从。
分析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提到的”像凤凰一样浴火重生“。