去年年底从 TSS 翻译的《Wicket：我们需要不同的表现层框架吗？》在今天引起了大家的共鸣。当初我是抱着很随意的态度翻译此文。各位也别冤我，表现层的框架实在是太多了，让人无从下手，无法确定到底哪个框架更具优秀，害怕顾此失彼。
通过今天的交流，我发现 TSS 的确没有说错，Wicket 结合了 Tapestry 与 Echo 的所有优点！Wicket 能够屏蔽 C/S 与 B/S 架构的区别，Wicket 模拟了 C/S 结构，也就是说不用考虑客户端与服务器之间的交互。比如在用 JavaScript 和 XMLHttp 写复杂页面逻辑的时候，脑子里始终在考虑这是 Client（浏览器），请求被提交到 Server，想着：“这是两个完全不同的环境”，需要做很多像避免刷新页面这样额外的工作。而在使用 Wicket 的时候，完全可以认为是在使用 Swing 进行开发，或者是 VB，这样的话，脑海里不会存在所谓的 Client（浏览器）与 Server 的概念。于是，客户端的数据与服务端的数据就可以不加分别（实际上是 Wicket 帮你做了很多工作，仅此而已）。
更令人兴奋的是 Wicket 支持不同的客户端，比如 HTML、Flash/Flex、Swing。就是说，忽然有一天要把之前做的系统的 UI 层更换成 Flex，这该怎么办？按照现有的手段，我认为很棘手（至少不会很轻松吧），在 Wicket 中，这一切仅仅通过简单配置就可以实现这种切换，你觉得是不是很美妙？
网友 Alex Chew 指出，选择框架的时候需要考虑：
1、支持不同的客户端，比如HTML，Flash/Flex，Swing。
2、支持软件过程，能够合理的进行工作分割。
3、容易维护，能够通过某种方式如 MDA 进行代码生成。
Wicket 都能很好的满足以上条件。行了，就说到这里吧。
最后，感谢 Alex Chew！
|
