10

作为一名 Java Web 应用程序开发人员，我去年使用 JSF (SUN) 作为我的 Web 应用程序的框架。我不得不说我很喜欢使用它，它使开发更容易。

最近看了很多关于JBoss Seam的好东西，但还是没有遇到用过的人。从我所读到的，似乎 SEAM 是 JSF 的下一步。

因此，我的问题是，对于使用过 SEAM 的您：当您使用这项技术时，您遇到过什么缺点吗？你会说使用它感觉很自然吗？

4

8 回答 8

27

像 SEAM 或 Grails 这样的任何框架的优势在于它是更高级别的抽象。它会为您处理底层细节，如果设计和编写得当，它会让事情变得更容易。

像 SEAM 或 Grails 这样的任何框架的缺点是它隐藏了很多细节。如果你不了解底层发生的事情，如果你被卡住并且对为你生成的代码一无所知，你会发现自己陷入了一个麻烦的世界。

另一个缺点是他们构建到模型中的假设可能并不总是你想要的。但是改变他们意味着打破他们为你铺设的道路，这并不容易。

我的建议是使用该框架并欣赏它带来的优势，但不要以它们为借口停止学习下面发生的事情。做一个可以在没有框架的情况下手动编写整个事情的人，但选择使用它来发挥它提供的杠杆作用。

于 2009-08-08T20:44:21.890 回答
10

我在 IceFaces 的一个正在进行的大型项目中使用了 Seam。Seam 肯定比使用普通的 JSF 好得多（请参阅 Damo 发布的链接，上面有几个答案）。

但是，我记得的一些问题：

  • 单元测试：让 SeamT​​est 正常工作，尤其是在持续集成构建中非常困难，请在网络上搜索“SeamT​​est 问题”。另请参阅：有没有人成功运行嵌入 Jboss、Seam 和 Maven 的集成测试？
  • 开发人员做事的多种方式，并且没有记录太多的最佳实践。因此，您必须花时间找出最适合您的项目团队的方法。例如，在实现表单时，以下是潜在的标签（注意其中一些是重叠的）：

Facelets <ui:repeat>

JSTL <c:forEach>

JSF <h:form>

ICEFaces <ice:selectOneMenu>

JSF <f:selectitems>

缝合 <s:button>

  • 性能值得怀疑，尤其是 IceFaces，这里有一篇相关文章 此外，您需要 Seam 的“大师级”知识才能做正确的事情，默认方式会让您陷入困境。有关详细信息，请参阅本文：将数据驱动的 JSF/Seam 应用程序加速两个数量级 - 第 1 部分
  • 由于 Seam 3 即将推出，并且应该使用 2 个新规范（JSF 2 和 WebBeans），这留下了关于 Seam 2 上的项目会发生什么以及事情变得稳定需要多长时间的问题
  • 学习曲线。恕我直言，seam 试图做的太多，给你像 iText、Quartz、JExcel、jBPM 等东西的包装器。Seam 与第三方框架的集成预计比最新版本落后一步。例如，我们必须直接集成 jBPM，因为我们需要一些最新的特性。
  • 可能是因为 JPA 1.X 中缺少条件查询，您实现动态搜索屏幕的方式（用户填写大量过滤器选项并且您必须生成动态 HQL）感觉非常不优雅，这是在使用推荐的“Seam 应用程序框架”EntityQuery 类，请参阅下面的链接以获取一个简单的示例，但您可以了解复杂过滤条件、处理空值、order-by 的预期内容：如何订购 EntityQuery在接缝应用程序中查询？
于 2009-08-10T06:28:06.513 回答
6

说“Seam 是 JSF 的下一步”是不正确的。Seam 不必使用 JSF 作为视图层。它也可以使用Wicket或GWT。

然而，当与 JSF 一起使用时，它在简化它方面做得很好。您的 XML 配置比标准 JSF 少，而且我经常忘记 JSF 在 EL 中没有对话上下文或参数化方法调用之类的东西。例如：

<h:commandButton action="#{myBean.sayHello('damo')}" value="hello"/>

它很容易使用，并且在任何地方都可以使用 POJO 的能力非常自由。它最大的缺点是与 JSF 相关的缺点：

  • 过分依赖 HTTP POST（这 s:button/link并不总能解决）
  • 大量的 javascript
  • 对 Getter/Setter 的过多调用
  • 看起来很讨厌的 HTML；ETC

在其他地方有足够多的页面详细说明 JSF 的缺点（请注意，这些不是对 Seam 的批评——而不是对 JSF1.x 的批评，许多在 JSF2.0 中得到了解决）

我不认为 Seam 是 JSF 的“下一步”，但如果您现在计划使用 JSF1.x，它和 Facelets 是至关重要的。

我认为JSF2.0和WebBeans是下一步。

于 2009-08-09T19:45:21.380 回答
2

如果你把记录器放在你的Seam 组件（例如resultList）上，你会看到Seam 多次调用同一个方法。这是Seam唯一令人讨厌的地方。但是 Seam 绝对“修复”了 JSF，它本身就很混乱。让我们看看 JSF2。不管这些问题，我很高兴使用Seam。

于 2010-07-26T06:36:34.967 回答
1

这对我来说感觉很自然，使用注释让生活更轻松。我什至无法想象使用 getAttribute/getParameter 框架。一个缺点是 seam-gen 还不能与 Maven 一起工作（但 Seam3 将基于 Maven）。我认为 Seam 让你专注于你想要实现的目标，而使用其他框架你必须思考如何去做。你有没有试过用 javascript/prototype/jquery 做 Ajax？与带有方法调用和重新渲染内容的接缝 Ajax 按钮相比，这真的很痛苦。使用 seam 和 Rich Faces 根本不需要 Javascript。对我来说，这是我用过的最好的框架。

于 2009-08-08T19:53:31.637 回答
1

我喜欢 JSF，不久前我评估了 Seam。JSF 是一个 Web UI 框架，而 Seam 是一个更通用的 Web 应用程序框架，它不仅集成了 JSF，还集成了会话上下文、工作流 (jBPM) 和对象持久性（最好是 EJB3）。我第一次被广告中的自动生成脚手架吸引到 Seam，但我从来没有让它与我的企业数据模型一起工作。从那时起，我对 Spring Framework 和 Spring JSF 越来越感兴趣。它对我的吸引力在于更加模块化，如果您使用 iBATIS，它只需要像 Tomcat 这样的 servlet 容器，而不需要像 JBoss 这样的 Java EE 容器。春天已经存在了更长的时间，并且拥有更大的思想份额。

ICEfaces 也非常适合 JSF 和 facelets，无论有没有像 Seam 或 Spring 这样的应用程序框架，它都能很好地工作。

于 2009-08-09T20:04:49.607 回答
1

Seam 作为一个集成框架，在与您想使用的其他框架搭配使用时，确实会显示出它的实用性。

如果您已经打算使用 EJB 和 JSF，那么 SEAM 就是杀手锏。

如果您打算使用 JSF（以及它的任何相关工具，如 IceFaces 或 RichFaces），SEAM POJO 可以大大简化您的设置，并让您可以访问 seam 提供的生命周期状态（对话等）。 )

如果您将 EJB 与 Wicket 或 GWT 一起使用，Seam 或许还可以为您节省一些配置，不过，我个人并没有在此配置中使用过它。

如前所述，Seam 的缺点是任何抽象框架都固有的：它对您隐藏了细节。如果它开始泄漏，你就有麻烦了。我还没有把它泄露给我，但我也花时间让自己对它的工作原理有一个很好的、基本的了解。EL 如何与 Seam Annotations 等一起工作。

您是否会发现 seam 有用取决于您将使用它的框架。Seam 肯定有它的最佳位置，但那个位置正在增长。Seam 绝对不是一个死项目。:)

于 2009-08-10T13:26:35.913 回答
0

您始终可以使用Factory annotation来避免一遍又一遍地调用相同的方法。工厂允许更新组件。

于 2012-06-14T16:33:37.630 回答