Rich Client Fashion
JDK1.5和C# 2.0没有太让人兴奋,即使再加上EJB3.0和WebForm 2.0,都没有Rich Client的大潮让人对今年抱有期待。
Rich Client的Fashion里,XAML和XUL是基于特定浏览器的实现,Flex和Laszlo是基于Flash的实现,Eclipse也有自己的一套。不过,XAML还处在单细胞状态,而且基于.net;XUL就需要客户安装FireFox,而且似乎规模偏小,发展的空间不大。Flex版权太贵;而Laszlo又出身不够高贵且小命掐在MM手里。Eclipse的rich client还没有试用但估计占有市场不易。
可见2004年末一切都各有缺点还是乱势,因此只当没事发生继续等待不是什么罪过,现在项目中强行使用只会代价巨大,而且容易选型失误。
但还是,忍不住热了一下身,同事试用Flex的时候,经常过去插上两脚。最后同事的小项目做完,自己也了解了Rich Client的实际东西,发现预热一下自己还是很重要的,今年的RIA潮流趋势、升级资讯一定会雪片般飞来,实践过的,就能实际的分析这些资讯,懂得其中的厉害。没有动手做过的就只能浑浑噩噩的人云亦云,或者自己袖手空谈了。
Rich Client的三个代表
综合XUL和Flex,Laszlo,一个Rich Client的方案,一定要提供下面三样东西:
1. 表现层的控件。
不能再依靠Html的<Table>, <Div>慢慢画控件了,如C/S程序般直接提供应用的控件标记。
2. 消息处理机制
同样W3c DOM的消息机制是用于Web Site上的,应用必须有和C/S程序差不多的消息机制,虽然和W3c的可能差异不算很大。
3. 与后台交互的能力
form submit页面刷新的交互方式被千百人怒骂,所有做过Desktop开发的同志都觉得怎么B/S下交互这么麻烦。
而Flex很有代表性的提供了三种交互方法:
第一种是Web Service,最标准同样也是最麻烦,最增加开发工作量的方法。
第二种是Http Request,类似XMLhttp,与第一种一样是面向过程的,前后台之间传输的经常是XML格式的数据,需要与对象相互转换。好处是额外的工作量比WS少,前台直接请求后台的.do即可,可以在Rich Client和普通Web Browser方案之间切换。
第三种是Remote Object,这是最OO,最贴近C/S开发模式的方法,缺点是在服务器端用的是MM自己的AMF,所以要与Spring框架或者EJB打交道,就需要一个Proxy类来JNDI lookup(EJB) 或者BeanFactory.load()(Spring)。
Flex的最好参考资料
A. 入门文档:国内的好文章难找,论坛与QQ群也弱。所以建议直接从MM的官方网站上下载参考手册:
http://www.macromedia.com/support/documentation/en/flex/
B. 提高文档:依然只有MM开发者网站上的东西值得学习:
http://www.macromedia.com/devnet/flex/
同事语,看完Best Practices ,对Flex有了新的认识,里面的Sample都是很好。
同时 Christophe Coenraets 和Matt Chotin的blog也应该经常阅读
上一篇: 如何编写不可维护的代码
下一篇: 第五十三天补: JMS除错笔记
标签:
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有