Seam with JSF与Seam与GWT

Question

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

主要关切事项：

• 可伸缩性/性能
• 跨浏览器兼容性
• 学习曲线
• 生产力
• 所见即所得UI大楼
• 尽可能多地用Java编写代码的能力(如果可能的话，我可以访问JS/HTML/CSS，但最好不要)

Answer 1

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

• 正如@z00bs所提到的，使用GWT，您将拥有一个类似于app的桌面。因此，您将不使用/需要页面导航或页面操作特性的Seam。
• 从GWT到服务器的所有请求都是短期运行的。这意味着，您的大部分组件都是ScopeType.EVENT或ScopeType.STATELESS，您不需要/使用会话范围。
• 使用GWT而不是JSF可以减少服务器上的负载，因为您在客户机中保存了大部分状态。
• 不能在GWT中使用JSF/Seam生命周期。例如，您将失去生命周期中的模型验证部分。模型验证将仅通过使用实体管理器或手动触发。
• 当将Seam与GWT一起使用时，所有其他特性(如安全性、邮件或EL )仍在工作。

由于Seam以其JSF支持而闻名，因此您应该考虑另一个框架，例如春袋鼠，它也与GWT密切相关。

Answer 2

关于客户端开发您的应用程序，我们有同样的决定。

我们决定选择GWT，原因如下：

• 大多数开发都可以用java完成。由于我们在java开发方面有很强的背景，这将为我们节省大量时间。
• 我们可以使用所有众所周知和受欢迎的工具来实现，因为所有这些工具都是用java完成的。
• 我们的应用程序将是一个桌面，像，单一页面的网页应用程序，没有完整的页面刷新。此时，GWT似乎最适合这一需求(而且现在仍然如此)。
• 把大部分的状态推给客户，让他做大部分耗时的处理，对我们很有吸引力。这样，服务器就可以处理大量的同时请求，并且只需要连接到服务器，就可以同步客户机上的状态。
• 对单元测试 GWT代码的支持是好的，与MVP模式更好地结合在一起。
• 自从引入UiBinder以来，复杂UI的创建和样式设计变得更加容易和快捷。

对于你的主要关切：

• 跨浏览器兼容性主要由GWT本身来处理。
• WYSIWYG可以使用GWT设计者 (我必须说我从未使用过它；我喜欢自己构建UI .)
• GWT非常快，因为呈现都是在客户端完成的。
• 当您习惯于java时，生产力是很高的。
• 学习曲线主要取决于您使用的体系结构(MVP最初是复杂的)。
• 您的应用程序将扩展，因为服务器摆脱了大量昂贵的处理。

希望这能有所帮助。

(@kraftan很快就会考虑到Seam的选择)。

Answer 3

Seam提供的会话范围可以通过在客户端的内存中存储持久事务(如购物车)来很容易地在GWT中被替换。