个人对目前框架优缺点的一些想法和设想，写出来大家分享。
我接触的框架大概有以下：
struts,hibernate,jpa,spring,seam,jsf,wicket
其中以jpa,seam,jsf比较深入

以下我个人非常推崇：
seam的组件模型、状态管理和附加功能（比如规则，安全等等）
jsf的生命周期模型
jpa的pojo数据模型

我个人对以上框架的个人观点
struts，spring功能不够
hibernate、jpa不错，但有细节需要改进
jsf，wicket累赘于组件，绕了个大圈
seam很完美

我认为seam很完美，是因为seam就像积木，很容易拼装，而不是补丁打得一层又一层。
意思就是说，如果你了解seam的工作机制，你可以像拆装积木一样，轻松并且无累赘的组装产品，seam可以轻松的包装任何支持扩展的web框架。而不仅仅限于wicket和jsf，或者你还可以基于seam组件包装自己的框架

有人说seam基于jsf是鲜花插在牛粪上。我想做的就是利用seam的组件模型，结合jsf高度支持扩展的生命周期模型，构建一个相对完善的综合框架。

我的思路是这样的：

//在jsf的facesServlet的基础上改进，在init()和destroy()方法内初始化和销毁Contexts对象状态（请参考文尾链接），而不是监听器（在恢复视图阶段之前以及渲染后）的工作。
这样所有的协助类都可以作为组件被轻松管理，而不是像jsf一样为维护状态做较复杂的工作。

//放弃jsf的组件树模型，模拟jsp渲染，模仿seam的页面动作和页面参数：
为什么要这样做，jsf和wicket隐藏了http的工作原理，但http天生残疾，包装过度留下隐患。web和桌面应用不同，web组件几乎不可能极大丰富。
所有的普通请求都交由facesServlet控制器处理，包括渲染（把渲染功能从容器分离出来），这是jsf的优点。
所有的数据处理都通过el（或者说扩展过的seam el）连接。
整个请求过程实际由Pages类实例处理，包括渲染
去掉恢复视图阶段，因为生命周期不再围绕组件树进行。

//渲染，保有jstl和el的功能，实际上部分模拟了容器的行为。

//维持jsf可扩展的监听功能

//其他细节（文件上传等）

或者说，完全用带注解的seam组件构建一个拥有类似jsf生命周期的seam延伸框架

整个工作非常繁杂，深感基础不扎实以及经验不够。不足之处请指出。

相关链接：
http://seam.group.iteye.com/group/topic/8363
http://afadgaeg.iteye.com/blog/287770
http://afadgaeg.iteye.com/blog/260887


1 楼 yingfang05 2008-12-21 楼主不觉得ejb的分布式,群集和事务在大型应用上非常好吗? 2 楼 afadgaeg 2008-12-21 ejb适合分布式应用，可以选择是否与seam一起用，他们的功能有一部分重叠。seam内置了很多web特性，是ejb所不具有的。它们都是很好的积木，如果你用直接用ejb和servlet，就要再找很多的小积木来组装。
seam不是为了取代ejb而存在的。


我对目前的框架不满，有下面一些看法。
//servlet缺少类似seam的对话状态，这直接导致了struts之类的框架存在状态管理的弊端。
seam对servlet的上下文进行包装，但是打补丁不是好的解决办法。
//jsf规范要求用组件树，就限制了程序的自由性，而且jsf无法拆卸以单独使用部分功能。
//wicket之类与jsf差不多

就是一个问题
一个稍微大点的应用，设计困难，管理困难，修改困难。


还有，我改的东西只是seamListener运行之后的东西，与ejb无关，一样可以毫无修改的用ejb。
也许你很少用seam，所以误会了我的意思。

谢谢你的关注！ 3 楼 fangshun 2009-01-08 seam其实也有很多不完美的地方，在1.2版中它的启动初始化过程对自己内置的拦截器都有明确的位置和定义，但是对于自定义的拦截器确表现的是模糊，很弱的插入机制，不向jsf明确定义了自身的各种拦截器例如属性，变量，阶段的插入机制 4 楼 afadgaeg 2009-01-12 seam1.2我没用过，不过seam2很不错，它的插入机制还是较为完善的，不过seam侧重的是状态的维护以及提供安全管理等实用功能，实际上它的前端与jsf等是紧密耦合的，分离不易。