抛砖引玉：jboss seam和软件框架
大家用过seam的都请进来讨论，这里我先抛砖引玉一下看了网上多篇文章都提到jboss Seam有严重压缩了软件结构的问题。我有些感想和经验。
我先说说seam怎么个压扁了我们心爱的mvc:
1. vc压扁:
现象：在seam里，每个ejb加上@Name,马上摇身一变又成了seam component。而一个seam component就直接是jsf的managed bean了。在view层，我们可以不用任何java代码了，view被压缩。
原因：seam诞生的初衷，只是想缝合jsf层和ejb层，并提供state management的容器。这也是现在gavin king提倡的web bean概念。
2. mc压扁：
现象：ejb3 entity作为domain model被放进逻辑代码，被扔进client端。model和control混合了。
原因：ejb3 entity的可线性化，使得entity直接成了DTO了。而且，gavin king在例子里很喜欢在entity里放逻辑，一点都不吊贫血模式，现在充血entity成了seam下的特点。
（gavin king的反骨是很明显的，在seam里我们还能体会到他的叛逆精神，譬如，不管多少专家呼吁应用的stateless性，gavin king却始终强调stateful时代的到来。）
这么一下mvc变成了一层。也就说，一个标识成seam component的的ejb,即是持久层，也是企业逻辑层，还是表现层。seam example里几乎都是这样的一层结构。
难怪从框架师眼里，seam简直是种颠覆。但对，需要快速开发的程序员来讲，seam让ee应用的开发带了RoR的味道。
不知道大家对这样的压扁怎么看。
我个人的看法是，seam只是个servlet层的framework。它虽然可以整合jsf和ejb，但是事实上，每个seam component都是依附于ejb生存周期的。简单点说，就算一个seam component标志seam scope为application,如果你的ejb是stateless,这个seam component还会是非常短命。ejb container才是老大。从这个角度来看，seam是完全可以独立出来的。今年年初，一个spring社团的牛人加入jboss seam开发队伍，整合了seam和spring。使seam的发展方向变得更加的宽广了，即seam可以完全不需要ejb。由于这个seam component的独立性，seam做的应用结构就可以象橡皮糖样，你想拉开就拉开，你想压扁就压扁。
以下是我的一种结构拉伸。
合并的jsf和seam只用于表现层,状态管理完全用seam 的不同scope，逻辑层统统stateless，持久层ejb的dao和entity。具体点说就是jsf和seam放war,逻辑层一个独立ejb jar,持久层一个独立ejb jar.
如果大家有其他的拉伸方案，欢迎一起讨论 楼主的帖子似乎离抛砖引玉比较远啊，相当专业的说
个人感觉MVC模式结构相当清晰，把任意两个层混为一谈都不太好，现在手上的Struts加Hibernate用的挺满意
俺惯用的理解就是JSF+EJB+JPA
回复 #2 大镖客 的帖子
嘿嘿，ls,我不是把你引来了吗:D是啊，我也是想把层次拉开点，归根结底还就是JSF+EJB+JPA,只不过，把seam放jsf那里了这回。
seam压扁式结构如果一个人开发还可以，队伍分工开发那就惨了。我最初经历的seam项目，就是一层的，到最后解决svn conflict成了开发的主要工作。
所以现在再碰到seam项目，我坚决把seam分割在web project里，不让它再沾染任何ejb project。
ls所说的sh,ssh,还是经典啊。struts的Craig McClanahan，spring的rod johnson, hibernate的gavin king,三个framework的三个创始人，用一己之力彻底颠覆工业标准！
现在，世界航母级公司制定出的的新标准，还不是跟着他们的理念走？
页:
[1]