|
这个主题共有 16 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
|
|
|
翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年07月02日 17:02
|
回复
|
|
最近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
|
|
|
|
|
|
回复:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年08月05日 14:18
|
回复
|
|
|
|
|
|
|
|
回复:回复:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 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修改过]
|
|
|
|
|
|
re:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 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修改过]
|
|
|
|
|
|
回复:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年08月08日 22:57
|
回复
|
|
[quote]当然有人一直倡导Spring+IBatis，其实我有一个极端观点：当前JavaEE程序中，SQL用得越多，说明，其OO架构设计越差，或者说程序员自身OO素质越差。[/quote]
现在的项目中就是使用Spring+Hibernagte+iBatis，Hibernate在级联操作方面并不是很好操作，iBatis是为了进行复杂的SQL查询来使用的，在查询中大量地使用了sqlMap，实然有个问题，对于复杂的查询，其它是由于复杂的业务逻辑带来的(较复杂的SQL，其实已经是数据库编程方面的问题)，那么，我们可否将这种复杂性放入业务层，但这事必要多次对数据库进行查询，也事必会影响性能，小项目的话，可能可能忽略，但访问量很大的情况下，iBatis还是比较不错的选择。
|
|
|
|
|
|
回复:回复:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年08月09日 17:12
|
回复
|
|
>我们可否将这种复杂性放入业务层，但这事必要多次对数据库进行查询，也事必会影响性能，小项目的话，可能可能忽略，但访问量很大的情况下，iBatis还是比较不错的选择。
由于和本主题不太相关，不说太多，我认为这个观点还是有些问题，Evans DDD厚厚一本书就是教我们如何用对象来表达复杂的业务，由此产生的频繁数据查询可以使用对象缓存降低，越是访问量大，对象缓存越是有效，所以，性能已经不成为阻止使用JPA这样简洁OO持久技术的障碍。
|
|
|
|
|
|
回复:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年08月09日 17:14
|
回复
|
|
未来多层框架组合可能更加多元化：
struts1.x +Spring + JPA
struts2.x +Spring + JPA
struts2.x +Spring + Hibernate
jsf + Seam + EJB3
JSF + Seam + JPA/Hibernate
等等。
|
|
|
|
|
|
回复:回复:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年08月11日 15:05
|
回复
|
|
|
JPA 是规范。hibernate3.2是它的一个实现。
|
|
|
|
|
|
re:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年08月14日 08:49
|
回复
|
|
|
jboss seam的学习曲线太高了，在短时间内（在相当长的短时间内），个人认为很难迅速推广普及！
|
|
|
|
|
|
re:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年10月22日 14:32
|
回复
|
|
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修改过]
|
|
|
|
|
|
re:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年10月29日 13:21
|
回复
|
|
littlesuns, 找工作是要看工作的前途好不好，自己参与到其中可以扮演什么角色，至于用到什么具体技术，或者是你不喜欢的技术，其实都不是很重要，都是用Java，技术不熟悉可以学，何必画地为牢。
[该贴被abcx于2007-10-29 14:21修改过]
|
|
|
|
|
|
回复:回复:回复:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年11月01日 14:36
|
回复
|
|
当然有人一直倡导Spring+IBatis，其实我有一个极端观点：当前JavaEE程序中，SQL用得越多，说明，其OO架构设计越差，或者说程序员自身OO素质越差。
这个观点我不同意，在某些应用确实不适合用Hibernate或者JPA这种ORM框架，比如有些大型的ERP系统，还有一些对响应速度要求很高的系统，他们一般会采用写procedure方式来处理，ibatis在这方面是具有优势的。
另外一个系统的好坏，我始终用户的体验是第一位的，无论你的系统设计的多么优雅，多么OO，如果用户体验不好，我觉得这个系统还是失败的。当然我不是说OO不好，我的意思只是想说在某些情况下可以牺牲下OO换取更好的用户体验。
BTW:这个论坛的用户注册不太好用，如果能加个用户名是否存在的类似Ajax的校验就好叻，免得每次用户名重复都得重新写一次信息，呵呵，一个小建议^_^
|
|
|
|
|
|
re:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年11月03日 17:02
|
回复
|
|
>>当然有人一直倡导Spring+IBatis，其实我有一个极端观点：当前JavaEE程序中，SQL用得越多，说明，其OO架构设计越差，或者说程序员自身OO素质越差。
>这个观点我不同意，在某些应用确实不适合用Hibernate或者JPA这种ORM框架，比如有些大型的ERP系统，还有一些对响应速度要求很高的系统，他们一般会采用写procedure方式来处理，ibatis在这方面是具有优势的。
另外一个系统的好坏，我始终用户的体验是第一位的，无论你的系统设计的多么优雅，多么OO，如果用户体验不好，我觉得这个系统还是失败的。当然我不是说OO不好，我的意思只是想说在某些情况下可以牺牲下OO换取更好的用户体验。
----------------------------------------------------------
实际上对响应速度要求很高的系统，可以用缓存做到的，没什么比在内存中获取对象更快了吧! 另：是否OO好象与用户体验无关吧。
|
|
|
|
|
|
回复:re:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年11月05日 12:04
|
回复
|
|
|
|
|
|
|
|
回复:re:翻译：JBoss Seam 2.0蹦达出来了
|
发表: 2007年11月05日 13:07
|
回复
|
|
实际上对响应速度要求很高的系统，可以用缓存做到的，没什么比在内存中获取对象更快了吧! 另：是否OO好象与用户体验无关吧。
------------------------------------------------------------
我只是想说很多技术存在都有它合理的地方，比如有些大型的遗留系统：有几千张表，N多的业务逻辑实在Procedure中实现的，这个时候你是重新用Hibernate的方式来个彻底重构，还是采用ibatis来继承以前留下来的“财产”呢？
另外：我想说无论是否纯OO，这个都是一种方法学。就像在java世界一样，刚开始没有框架觉得开发很繁琐，现在框架太多，又有人想办法对这些框架整合一样。
|
|
|
|
|
|
这个主题有 16 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
注册
登陆
上一主题
下一主题
