翻译:JBoss Seam 2.0蹦达出来了

最近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

目前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路线是几成定局了。

这些消息动向对于当前开源黄金组合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修改过]

前几个月重温“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修改过]

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

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

>我们可否将这种复杂性放入业务层,但这事必要多次对数据库进行查询,也事必会影响性能,小项目的话,可能可能忽略,但访问量很大的情况下,iBatis还是比较不错的选择。

由于和本主题不太相关,不说太多,我认为这个观点还是有些问题,Evans DDD厚厚一本书就是教我们如何用对象来表达复杂的业务,由此产生的频繁数据查询可以使用对象缓存降低,越是访问量大,对象缓存越是有效,所以,性能已经不成为阻止使用JPA这样简洁OO持久技术的障碍。

未来多层框架组合可能更加多元化:

struts1.x +Spring + JPA
struts2.x +Spring + JPA
struts2.x +Spring + Hibernate
jsf + Seam + EJB3
JSF + Seam + JPA/Hibernate
等等。

JPA 是规范。hibernate3.2是它的一个实现。

jboss seam的学习曲线太高了,在短时间内(在相当长的短时间内),个人认为很难迅速推广普及!

Hibernate被EJB招安好像有段时间了,听说Gavin King也成为了JCP委员会的一员了吧,力挺Seam当然也是应该的。
毕业后做的第一个项目就是用Seam,那时刚出来,还是beta版(一年以前有去一家大公司面试,他们的PM竟然告诉我没有听过Seam(那时候1.0都出来了),然后因为做项目只用了Facelets+jsf+Seam+hibernate,人家要struts+spinrg+ibatis,被人BS了一把,一怒之下把他们的offer拒了),就一个简单的Bijection容器和aop的功能,连自己的标签库都没有,但是那时候Seam Component的scope就分的很细了,感觉Gavin他们在这方面还是下了一定功夫的,虽然大家一样,都是提供组件化,但是我bean scope的选择比你(spring1.x)多,而且在开发中的确会有这方面的需求,而且我不但可以injection,还可以outjection,的确是挺有意思的(spring2.x不就针对web加入了不同的scope吗?),不是有人说Gavin跑去做web Framework "who care",我想我还是会care一下的。
Gavin还是比较年轻,之前好像就因为spring和seam孰优孰劣的问题在blog上和人吵过,不过Rod如果因为这个原因就放弃spring+hibernate的组合,未免也太小家气了点,毕竟现在hibernate做的还是不错的,开源社区不应该是通过吵架来解决问题的。
上面说了这么多,没有贬谁褒谁的意思,Seam和Spring我都用过,对于各自的设计也有一些自己的见解和认识,Spring的所体现的lightweight的确是一种很优雅的方式,我个人是很推崇的。在这里只是想说,java之所以能存活至今,仍有着旺盛的生命力,和社区的这些大牛们是有着巨大的关系的,只是希望大家不要因为一些分歧就搞得你死我活,既然是openSource,百花齐放当然是最好的选择,这也算是一个想做JSF+Ajax却被人考struts而且快一个月没有找到工作的人的一点小小的牢骚吧。
最后,to ls,seam的学习曲线应该不算高吧(不知道怎么画的),它出现的目的就是简化开发,看看那个booking的例子就明白how easy了,文档也还详细。不过想要对原理寻根问底,恐怕是有点难了,一个JSF+hibernate就可以撂倒一大片了,哦,还有EJB3。
呼,好久都没有关注Seam了,想不到竟然有了这么大的动作,看来是要再看看了,还有遥远虚幻的JSF2.嗯...好像快没钱吃饭了,还是先去忙找工作的事吧.T_T
[该贴被littlesuns于2007-10-22 14:33修改过]
[该贴被littlesuns于2007-10-22 14:35修改过]

littlesuns, 找工作是要看工作的前途好不好,自己参与到其中可以扮演什么角色,至于用到什么具体技术,或者是你不喜欢的技术,其实都不是很重要,都是用Java,技术不熟悉可以学,何必画地为牢。

[该贴被abcx于2007-10-29 14:21修改过]

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

这个观点我不同意,在某些应用确实不适合用Hibernate或者JPA这种ORM框架,比如有些大型的ERP系统,还有一些对响应速度要求很高的系统,他们一般会采用写procedure方式来处理,ibatis在这方面是具有优势的。
另外一个系统的好坏,我始终用户的体验是第一位的,无论你的系统设计的多么优雅,多么OO,如果用户体验不好,我觉得这个系统还是失败的。当然我不是说OO不好,我的意思只是想说在某些情况下可以牺牲下OO换取更好的用户体验。

BTW:这个论坛的用户注册不太好用,如果能加个用户名是否存在的类似Ajax的校验就好叻,免得每次用户名重复都得重新写一次信息,呵呵,一个小建议^_^

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

>这个观点我不同意,在某些应用确实不适合用Hibernate或者JPA这种ORM框架,比如有些大型的ERP系统,还有一些对响应速度要求很高的系统,他们一般会采用写procedure方式来处理,ibatis在这方面是具有优势的。
另外一个系统的好坏,我始终用户的体验是第一位的,无论你的系统设计的多么优雅,多么OO,如果用户体验不好,我觉得这个系统还是失败的。当然我不是说OO不好,我的意思只是想说在某些情况下可以牺牲下OO换取更好的用户体验。
----------------------------------------------------------
实际上对响应速度要求很高的系统,可以用缓存做到的,没什么比在内存中获取对象更快了吧! 另:是否OO好象与用户体验无关吧。

你还是不懂oo

实际上对响应速度要求很高的系统,可以用缓存做到的,没什么比在内存中获取对象更快了吧! 另:是否OO好象与用户体验无关吧。
------------------------------------------------------------
我只是想说很多技术存在都有它合理的地方,比如有些大型的遗留系统:有几千张表,N多的业务逻辑实在Procedure中实现的,这个时候你是重新用hibernate的方式来个彻底重构,还是采用ibatis来继承以前留下来的“财产”呢?
另外:我想说无论是否纯OO,这个都是一种方法学。就像在java世界一样,刚开始没有框架觉得开发很繁琐,现在框架太多,又有人想办法对这些框架整合一样。