SEAM有什么缺点吗?

Avi*_*i Y 10 java jsf seam

作为一名java Web应用程序开发人员,我去年使用过JSF(SUN)作为我的Web应用程序的框架.我不得不说我非常喜欢使用它,它使开发更容易.

最近,我已经阅读了很多关于JBoss Seam的好东西,但我还没有遇到过使用它的人.根据我的阅读,似乎SEAM是JSF的下一步.

因此,对于使用过SEAM的人来说,我的问题是:当你使用这项技术时,你遇到了什么缺点?你会说你觉得这很自然吗?

duf*_*ymo 27

任何框架(如SEAM或Grails)的优势在于它是更高级别的抽象.它会为您提供潜在的细节,如果设计和编写得好,可以使事情变得更容易.

任何框架(如SEAM或Grails)的缺点是它隐藏了很多细节.如果你还没有了解到底下发生了什么,你就会发现自己陷入困境,如果你遇到困难并且对你生成的代码一无所知.

另一个缺点是,他们在模型中构建的假设可能并不总是您想要的.但改变它们意味着打破他们为你准备的道路,这并不容易.

我的建议是使用框架并欣赏它带来的好处,但不要以它们为借口停止学习下面发生的事情.是没有框架可以手工编写整个事物的人,但选择使用它来提供杠杆.

  • 为"能够在没有框架的情况下手工编写整个事物的人,但选择将其用于提供的杠杆". (4认同)

Pet*_*mas 10

我在使用IceFaces进行的大型项目中使用了Seam.Seam肯定比使用普通JSF要好得多(请参阅Damo发布的链接以上几个答案).

但是,我记得一些问题:

  • 单元测试:让SeamT​​est正常工作,特别是在持续集成构建中很难,在网上搜索"SeamT​​est问题".另请参见:有没有人成功运行嵌入式,Seam和Maven的Jboss集成测试?
  • 开发人员有多种方式可以做事,而不是记录太多的最佳实践.所以你必须花时间找出最适合你的项目团队的东西.例如,在实现表单时,这里是潜在的标签(请注意其中一些重叠):

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上的项目发生了什么以及需要多长时间才能使事情变得稳定
  • 学习曲线.IMHO seam试图做太多,给你包装iText,Quartz,JExcel,jBPM等等.而Seam与第三方框架的集成有望落后于最新版本.例如,我们必须直接集成jBPM,因为我们需要一些最新的功能.
  • 也许是因为JPA 1.X中缺少标准查询,你实现动态搜索屏幕的方式(用户填写了很多过滤器选项,你必须生成动态HQL)感觉非常优雅,这就是使用时推荐的"Seam应用程序框架"EntityQuery类,请参阅下面的链接以获取一个简单示例,但您可以了解复杂过滤条件的预期,处理空值,order-by和all:如何订购EntityQuery在缝应用程序中查询?


Dam*_*amo 6

说"Seam是JSF的下一步"是不正确的.Seam不必使用JSF作为视图层.它也可以使用WicketGWT.

但是,当与JSF一起使用时,它可以很好地简化它.您拥有的XML配置比标准JSF少,我经常忘记JSF没有像EL中的对话上下文或参数化方法调用那样的东西.例如:

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

它易于使用,并且在任何地方使用POJO的能力都非常自由.与JSF相关的最大缺点是:

  • 过分依赖HTTP POST( s:button/link并不总能解决)
  • 很多javascript
  • 过度呼叫Getters/Setters
  • 讨厌的HTML; 等等

有足够多的页面详细说明了JSF 在其他地方的缺点(请注意,这些不是对Seam的批评 - 而不是JSF1.x,而且很多都是在JSF2.0中解决的)

我不相信Seam是JSF的"下一步",但如果你现在计划使用JSF1.x,那么它和Facelets是至关重要的.

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