我认为我们主要需要考虑两点：（1）你喜欢用声明式的方式还是编程式的来定义用户界面？
（2）在客户端到底有多少功能可以被真正执行？
还有一个问题，你希望的类型安全是什么样的。 所有这些问题几乎都是正交的。例如，GWT 提供类型安全的，编程式的，客户端的方案。另一方面，Wicket 提供类型安全的，编程式的，服务器端的方案。
JSF 在某种程度上是类型安全的，声明式的，服务器端的方案，如果需要的话，你也可以选择编程式的方式。每种方式都有它自己的优缺点，但是我认为 JSF 的方法是强迫性的： 首先，我必须用一种声明式的语言来定义用户界面。用户界面本质上是分层的，而我希望我的代码结构能够反映这种本质。我对于使用 swing 风格的 代码来建立用户界面总是觉得别扭。这种代码看起来总是很丑陋而且难以维护——有点象通过遍历 DOM 树来解析 XML 的 Java 代码。这里存在基本的结构性的 断层。
对于用户界面中动态性强的部分，编程式的操作当然更有效。但是，动态性强的部分是很少的。除了个人控制级别的界面以外，大多数用户界面是静态的。而 JSF 在处理动态性的界面时也是很强大的，它允许你在 Java 代码中直接操纵 JSF 组件。当然，你可以选择使用 JavaScript 代码来操作浏览器中的 DOM 对象。（总有一天，有人会建立一个 JSF 实现，使得客户端可以访问 JSF 组件树，但是我们现在没有实现这个功能。）
其次，我不认为把更多的状态和应用逻辑放在客户端执行会减少很多开发工作。有太多事情只能在服务器端有效的处理：持久化，安全，数据级别的并发，等等。如 果你把试图把你的应用代码放到客户端，那么你最终会回到我们 3、4 年前的状态，会有这样一种架构，其特点是：有一个无状态的服务层，一些数据传输对象，细 粒度的手工方式的获取数据以及合并数据变化。这是痛苦的编程模式，我们采用有状态的组件和会话范围的持久化上下文——这两种都是服务器端技术——刚刚从其中逃脱。
使用 RichFaces 和 Seam，你可以创建这样的用户界面：异步的获取数据，交互式的更新视图，异步的响应用户交互，交互式的应用变化，这些动作都处 于一个良好定义的乐观事务中，没有任何烦人的重复工作。当然，学习 JSF 和 RichRaces 比使用其他方式要多花一些时间，但是从长期来看这些代价是物 有所值的。
我所认为的 JSF 方式的最大的弊端目前很少被提及：使用 EL 把视图绑定到模型时缺乏类型安全。我理想的环境应该支持一种真正类型安全的声明式语言来定义用户界面。可惜，Java 不能真正支持创建这样的 DSL。遗憾。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论