个人对目前框架优缺点的一些想法和设想，写出来大家分享。

我接触的框架大概有以下：
struts,hibernate,jpa,spring,seam,jsf,wicket
其中以jpa,seam,jsf比较深入

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

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

我认为seam很完美，是因为seam就像积木，很容易拼装，而不是补丁打得一层又一层。
意思就是说，如果你了解seam的工作机制，你可以像拆装积木一样，轻松并且无累赘的组装产品，[b]seam可以轻松的包装任何支持扩展的web框架。[/b]而不仅仅限于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延伸框架

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

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