在RIA大潮里湿了一下身--Flex

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，而且XUL似乎规模偏小。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. 入门文档：国内的好文章难找，论坛与ＱＱ群也弱。所以建议直接从ＭＭ的官方网站上下载参考手册：
          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也应该经常阅读