SEAM有什么缺点吗？

Question

作为一名Java Web应用程序开发人员，我在过去的一年中使用了JSF（SUN）作为我的Web应用程序框架。我必须说我相当喜欢使用它，它使得开发变得更加容易。

最近，我读到了很多关于JBoss Seam的好东西，但我仍然没有遇到过使用它的人。从我所读到的内容来看，似乎SEAM是JSF的下一步发展。

因此，我的问题是：对于那些使用过SEAM的人，您是否遇到了任何缺点？您会说在使用它时感觉自然吗？

- Avi Y

Answer 1

任何框架如SEAM或Grails的优点在于它们处于更高层次的抽象之上。它们为您处理了底层细节，如果设计和编写得好的话，会使事情变得更容易。

然而这类框架的缺点在于它们隐藏了很多细节。如果您从不了解其底层运作，那么当您被困住并且对为您生成的代码一无所知时，您可能会陷入麻烦之中。

另一个缺点是其构建模型所依据的假设可能并不总是符合您的需求。但改变它们意味着打破为您铺就的道路，这并不容易。

我的建议是使用框架并欣赏它带来的优势，但不要把它们当成停止学习底层发生的原因。成为能够手写整个框架的人，但选择使用它为您提供的支持。

- duffymo

---

+1 表示同意 “成为那个可以手写整个东西，不依赖框架，但选择使用它来获得优势的人。” - firstthumb

这更多是一种哲学和原则，而不是技术解释。但我很喜欢它 :) - Hendy Irawan

Answer 2

我在一个大型的IceFaces项目中使用了Seam。与使用纯JSF相比（参见Damo在前面几个答案中发布的链接）Seam确实更好。

但是，我记得有以下一些问题：

• 单元测试：使SeamTest正常工作尤其是在持续集成构建中是困难的。请在网络上搜索“SeamTest issues”。另请参见此处：有人成功地使用Jboss嵌入式、Seam和Maven运行集成测试吗？
• 开发人员有多种方法可供选择，但记录下来的最佳实践不多。因此，您必须花时间找出对您的项目团队最好的方案。例如，在实现表单时，以下是可能的标签（请注意，其中一些重叠）：

Facelets<ui:repeat>

JSTL<c:forEach>

JSF<h:form>

ICEFaces<ice:selectOneMenu>

JSF<f:selectitems>

Seam<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类也是如此。参见下面链接的简单示例，但你可以对复杂的筛选条件、处理空值和排序等问题有一个大致的了解：如何在Seam应用程序中排序EntityQuery查询？

- Peter Thomas

Answer 3

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

但是，当与JSF一起使用时，它可以很好地简化JSF。你需要比标准JSF更少的XML配置，并且我经常忘记JSF没有像对话上下文或EL中的参数化方法调用这样的东西。例如：

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

它易于使用，而且可以在任何地方使用POJOs非常令人解放。它最大的缺点与JSF相关：

• 过多依赖HTTP POST（s:button/link并不能总是解决）
• 大量JavaScript
• 过多调用Getter/Setters
• 难看的HTML等

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

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

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

- Damo

Answer 4

如果你在Seam组件（例如resultList）上放置了日志记录器，你会发现Seam调用相同的方法很多次。这是Seam唯一令人讨厌的地方。但是，Seam肯定“修复”了JSF本身非常混乱的问题。让我们看看JSF2。尽管存在这些问题，我非常高兴使用Seam。

- Leonardo

Answer 5

对我来说，使用注释感觉很自然，使生活更加轻松。我甚至无法想象使用getAttribute/getParameter框架工作。一个缺点是seam-gen目前还不能与Maven一起使用（但Seam3将基于Maven）。我认为Seam让你专注于你想要实现的内容，而其他框架则需要考虑如何实现。你有没有尝试过使用javascript/prototype/jquery进行Ajax？相比之下，与seam Ajax按钮和方法调用以及重新渲染相比，这真的很痛苦。在seam和Rich Faces中，真的不需要使用Javascript，对我来说，这是我使用过的最好的框架。

- martin

Answer 6

我喜欢JSF，不久前我评估了Seam。JSF是一个Web UI框架，而Seam是一个更通用的Web应用程序框架，它集成了不仅JSF，还有会话上下文、工作流（jBPM）和对象持久性（最好是EJB3）。我最初被Seam宣传的自动生成脚手架所吸引，但我从未能够将其与我的企业数据模型配合使用。从那时起，我对Spring Framework和Spring JSF越来越感兴趣。它吸引我的是更模块化，如果您使用iBATIS，它只需要像Tomcat这样的Servlet容器，而不是像JBoss这样的Java EE容器。Spring已经存在更长时间，并且拥有更大的思维共识。

此外，ICEfaces与JSF和facelets非常搭配，无论是否使用Seam或Spring等应用程序框架都可以完美运行。

- Piers C

---

Seam不需要JBoss，可以在Tomcat/Glassfish/WebSphere上运行，但Spring肯定有更高的知名度。 - Damo

虽然不需要JEE容器，但Seam似乎旨在使用JSF与EJB3。Spring被认为更加中立，可以处理使用Hibernate、iBATIS或其他框架管理的POJO。 - Piers C

Answer 7

Seam作为一个集成框架，当与其他你想使用的框架配对时，真正展现了它的实用性。

如果你已经在使用EJB和JSF，那么SEAM就是一个杀手级的选择。

如果你将使用JSF（加上任何相关工具，如IceFaces或RichFaces），那么SEAM POJOs也可以简化你的设置，并让你访问Seam提供的生命周期状态（conversation等）。

如果你正在使用EJB与Wicket或GWT，Seam也可能能够帮助你节省一些配置，尽管我个人没有在这种配置中使用过它。

正如所说，Seam的缺点在于任何抽象框架都固有的问题：它会隐藏细节。如果它开始泄漏，你就会遇到麻烦。我还没有遇到过泄漏的情况，但我花了时间给自己一个良好的基本理解，包括EL如何与Seam注释等配合工作。

无论你是否会发现Seam有用，取决于你将要使用它的框架。Seam绝对有其优势，而且这个优势正在不断增长。Seam绝对不是一个死项目。 :)

- Drew

Answer 8

您可以始终使用工厂注解来避免反复调用同一方法。工厂允许更新组件。

- James