使用JST与JSF诉Seam进行联系

Question

有人能比较和对比两种解决方案吗？我对Seam或JSF知之甚少，虽然我熟悉GWT的工作方式，非常喜欢它的理论。

主要关注点：

• 可扩展性/性能

• 跨浏览器兼容性

• 学习曲线

• 生产率

• WYSIWYG UI构建

• 使用Java编写尽可能多的代码的能力（如果可能，我可以触摸JS / HTML / CSS，但最好不要）

Answer 1

关于您的应用的客户端开发，我们做出了同样的决定。

由于以下原因，我们决定选择GWT：

• 大多数开发都可以在java中完成。由于我们在Java开发方面有很强的背景，这将为我们节省大量时间。
• 我们可以使用所有众所周知和受欢迎的工具来实现，因为所有工具都是用java完成的。
• 我们的应用程序将是一个类似桌面的单页面Web应用程序，没有完整的页面刷新。在这一点上，GWT似乎最适合这种需求（而且它仍然存在）。
• 将大部分状态推送给客户，并让他做大部分耗时的处理工作。通过这种方式，服务器可以处理大量的同步请求，只需要在服务器上同步状态即可与服务器建立连接。
• 对Unit Testing GWT代码的支持很好，与MVP pattern一起更好。
• 自UiBinder引入创建和样式复杂的UI以来，已经变得更加轻松和快捷。

主要关注：

• 跨浏览器兼容性主要由GWT本身负责。
• GWT Designer可以实现WYSIWYG（我必须说我从未使用过它;我喜欢自己构建UI ...）
• GWT非常快，因为渲染都是在客户端完成的。
• 当你习惯使用java时，生产力很高。
• 学习曲线主要取决于您使用的架构（MVP最初很复杂）。
• 您的应用程序将扩展，因为服务器无需昂贵的处理。

希望有所帮助。

（有关选择Seam的一些考虑因素很快就会来自@kraftan）。

Answer 2

关于应用程序的服务器端实现，在使用GWT而不是JSF时，必须考虑以下几点（pro / con是主观的，所以你应该决定）。

• 正如@ z00bs所提到的那样，使用GWT你会有一个类似app的桌面。因此，您不会使用/需要Seam的页面导航或页面操作功能。
• 从GWT到服务器的所有请求都是短时间运行的。这意味着，您的大多数组件都是ScopeType.EVENT或ScopeType.STATELESS，并且您不需要/使用会话范围。
• 使用GWT而不是JSF减少了服务器上的负载，因为您在客户端中占据了大部分状态。
• 您不能将JSF / Seam生命周期与GWT一起使用。例如，您在生命周期中丢失了模型验证部分。模型验证只能通过使用实体管理器或手动
触发
• 使用Seam和GWT时，所有其他功能（如安全性，邮件或EL）仍然有效。

由于Seam以其JSF支持而闻名，你应该考虑另一个框架，例如与GWT密切相关的Spring roo。

Answer 3

Seam提供的会话范围可以通过在客户端的内存中存储持久交易（如购物车）在GWT中轻松替换。

Answer 4

既不！如果你绝对没有必要，请不要使用seam（或者jsf）！ java上有很多更好的网络技术。