翻译:JBoss Seam 2.0蹦达出来了

07-07-02 banq
最近JBoss Seam 2.0 Beta出来了,2.0马上走入大家的视线,Seam在功能强大时已经开始冗肿复杂,融入了JBoss很多其他项目,如 jBPM GWT(Google Web Toolkit) Ajax4JSF Security 。

Seam开始提出一个Web Beans概念,Web Beans作为一个提交标准概念注重于:

* 包含双向注射(Ioc)组件模型,可映射到ELthe basic component model including bijection/resolvers and mapping to EL

* the extensible context and context propagation/demarcation model

* persistence context / transaction management

* bindings to JSF and EJB

Seam还在非JTA环境下提供了一个事务抽象,New transaction abstraction layer with support for non-JTA environments,这点让我比较感兴趣,这可能也是想能让Seam直接在Tomcat下跑,不过是否又重新轮子?增加框架复杂性。

Gavin King 针对日渐冗肿的Seam2解释是:这些不同功能在不同包下面,你不用那些功能就不要理会那些包就可以了。哑口无言了吧?

有人将Seam和Spring进行了比较,认为Seam优点是统一的组件模型和灵活极致的依赖注射Ioc,而Spring的注射虽然属于上一代,但是经过实战验证,有人又担心这样一个自动配对注射Ioc autowiring 和 outjection 是否在实践会过于冒险,在大项目容易混乱? 我个人觉得这个观点不值得担心:JdonFramework也是autowiring,在复杂项目中反而觉得开发效率比较高。

TSS讨论网址:

http://www.theserverside.com/news/thread.tss?thread_id=45998

    

banq
2007-08-05 14:18
目前Hibernate作者Gavin King 已经走到Spring对立面去了,Gavin King 力挺EJB3,还是回到EJB阵营了,这是一个很有趣的结局。

JCP看来是把JBoss SEAM推荐的JSF + EJB + JPA 架构作为Web Beans JSR,这对于Spring阵营来说,一直游离于标准之外,可不是一件好事。

Gavin King 和不少 Spring 团队人员之间就 JBoss 和 EJB 3 vs. Spring“类 EJB 容器”(这是 Gavin 的叫法)问题爆发了一场大规模舌战。Spring 团队主张,JPA 是新 EJB 规范的主要价值所在,而在依赖注入和 AOP 能力方面,Session Bean 仅仅是 Spring 的很小的子集。他们在力挺 Spring + JPA。Gavin King 反击说,他们(Spring 团队)试图通过力推 Spring 的方式,进一步加强 Spring 的市场锁定,而不是“通过规范提供的扩展点为 EJB 3 创建附加组件”。

http://www.jroller.com/raible/entry/ejb3_running_in_tomcat_as

目前看来,存在三个阵营,Sun/JCP、JBoss 和 Spring。社区将齐聚 EJB 阵营还是仍然对其嗤之以鼻?是继续固守 Spring + JPA 还 Spring + Hibernate 阵营?现在看来Web Beans 规范确定Seam路线是几成定局了。

banq
2007-08-08 11:21
这些消息动向对于当前开源黄金组合Struts+Spring+Hibernate可能有所动摇影响。

下面谈谈我个人观点:

Struts 1.x是开发Tomcat的牛人做的,才华横溢啊,一直受人批评的ActionForm其实对于复杂项目是可接受的,属于设计领域的边界对象,struts2.x去除ActionForm,容易将模型对象和边界对象混合在一起,势必导致程序员将Model直接引入表现层可能对Model会加入很多界面因素,Model进而变得混乱。

Struts2.x可以说是被Webwork劫持的,Struts2.x中到处是opens*(出OSCache那个开源组织)的影子,除了可将Model和业务层Bean通过Ioc直接注射之外特点,其他不比struts 1.x高明多少。这也许是struts走向下坡的开始。JSF/Tapestry对struts的优势越来越大了。

在业务层框架方面:Spring由于没有能够进入Web Beans标准,这方面被JBoss Seam排挤,未来前途担忧。更主要是Spring要接受Seam的挑战。

原来Spring+Hibernate最好搭档,由于Hibernate创始人推出Seam,开始结束历史上最好得蜜月期间,从此可能分道扬镳,是走向了Spring+JPA了,还是Seam+Hibernate等。

当然有人一直倡导Spring+IBatis,其实我有一个极端观点:当前JavaEE程序中,SQL用得越多,说明,其OO架构设计越差,或者说程序员自身OO素质越差。

[该贴被banq于2007年08月08日 11:52修改过]

[该贴被banq于2007年08月08日 11:52修改过]

lgx522
2007-08-08 16:02
前几个月重温“without EJB”,印象很深的是在篇尾Rod对Spring和EJB的性能评测。毕竟事实胜于雄辩,Rod这一招令很多对Spring怀有疑虑的同道们心服口服。

在本人的Spring+Hibernate实践中,此黄金组合的确性能优秀,适用范围也很广。最近尝试Swing调用Spring RMI,性能相当出色。正尝试在企业内部应用中大量使用。

本人对Struts、JSF、WebWork、Spring MVC都小有应用,Struts1.x的性能最高,对Struts被WebWork劫持一事,本人也是相当遗憾。个人观点,这一合并对两者都不利。

EJB3看过一点点,简化了很多。由于省却了xml的繁琐,甚至比Spring还简化。性能比重量级的EJB2似有提升,不知与Spring相比如何?这一点本人还是相当关心的。毕竟Rod所强调的“问问电脑”,实是至理名言。

既然EJB3与Spring上设计上已难分高下,那么剩下的问题就是性能和易用性了。希望诸位同道能勇于实践,解开这两个谜团。如果这两者的对比也不相上下的话,那么为了标准化,我们Java界的确是应该统一使用Seam了。

[该贴被lgx522于2007年08月08日 16:03修改过]

[该贴被lgx522于2007年08月08日 16:03修改过]

scorpioer
2007-08-08 22:57
摘录
当然有人一直倡导Spring+IBatis,其实我有一个极端观点:当前JavaEE程序中,SQL用得越多,说明,其OO架构设计越差,或者说程序员自身OO素质越差。

现在的项目中就是使用Spring+Hibernagte+iBatis,Hibernate在级联操作方面并不是很好操作,iBatis是为了进行复杂的SQL查询来使用的,在查询中大量地使用了sqlMap,实然有个问题,对于复杂的查询,其它是由于复杂的业务逻辑带来的(较复杂的SQL,其实已经是数据库编程方面的问题),那么,我们可否将这种复杂性放入业务层,但这事必要多次对数据库进行查询,也事必会影响性能,小项目的话,可能可能忽略,但访问量很大的情况下,iBatis还是比较不错的选择。

猜你喜欢
4Go 1 2 3 4 下一页