如何构建自己的Framework（银弹）,适应用户多变的需求 (2)

(2)关于视图层的选择

 在上篇“重新发明轮子的‘惑’与‘祸’”篇中，我提到，基于Java和J2EE的解决方案，真的是太极大丰富了，丰富到足可以让你不知道该听哪位误人子弟的大侠说的对，而这位大侠背后可能还代表着有某个有强烈商业目的的商业组织。前几年，凡是论坛混战与互相谩骂的，无不是在Java框架之间内部进行的（语言本身之争的除外），.net阵营倒是出奇的平静，那是因为Microsoft发明了ASP.NET之后，之后的技术一直在无聊的徘徊，除了重大的失误之外，没有任何重大的创新。而基于J2EE阵营这边，则是轮子 发明了一个又一个。

 

我今天重新看了Wicket的解决方案，发现Wicket与ZK的核心思想与事实上的解决方案，无任何不同之处，唯一的区别就是Wicket是基于HTML语言本身加标签，而ZK则是重新弄了一个基于XUL的ZUL语言。3年前，我还在ZK上花了大约半年的功夫，去研究基于ZK的解决方案。后来发现Flex SDK免费和Flex开源后，则毫不犹豫的转向了Flex.

 

Wicket与ZK相比较而言，当然是Wicket的友好性更强一些，毕竟你只需要掌握HTML语言就可以了，不用再去研究一门新的脚本语言ZUL.另外，Wicket与Taspetry的核心思想与解决方案，也是蛮像的。

 

 

Flex做 MIS/ERP/进销存之类的后台系统，还是非常合适的。但是对于网店系统和其它基于Web的系统来说，Flex编译之后的.swf文件，还是太大了，运行速度还是蛮慢的。如果是对于搜索引擎而言，Google对Flash支持的很好了，只是本地搜索引擎baidu支持的不好。考虑到 国内行情和带宽速度，对于前台网店系统，还是选择一个 比较好的视图层解决方案比较好。要是中国的带宽达到了韩国带宽的速度一半，估计Flash文件大，也不是问题了。