关于Seam,一些想说的

最近的一个项目采用了JSF,因为JSF类似于JSP,只是提供了一种基本的页面表现技术,以及导航规则等等,无法算一个实际可用的应用型框架,于是寻找一个基于JSF的健壮的Framework就成了一件必要的事情。从Struts的页面链接看到了Shale,据说是完全抛弃了Struts的一种基于JSF的框架,花了点时间研究了一下,里面的Remoting和View Controller子包确实符合我的一部分需求。
因为项目整体一期规模比较小,就采用了Shale的这两个包,其它的比如权限控制等等就自己去简单实现了。项目完成后,总结JSF使用感觉的时候发现了下面一些问题。
1,XML配置太过于繁琐
2,异常处理太过于简陋
3,页面初始化的控制。虽然提供的ManagedBean看起来非常强大,但是对于单个页面的生命周期的严格控制不得不侵入生命周期去写一些代码。
4,页面流的控制
项目结束后,作为后续的开发准备,于是开始着手寻找一个更加强大的框架。简单的搜索了一下,很多地方都提到了JBoss的Seam这个东东。有两篇文章吸引了我,《深入浅出JBoss Seam》《Seam - 无缝集成 JSF,第 1 部分: 为 JSF 量身定做的应用程序》。其中第二篇中具体谈到了一些JSF的缺陷,恰好击中了我的心坎,于是马上着手准备Seam。但是看Seam的文档中提到了几个东西,JBoss,Hibernate,EJB3,这些都是我不会采用的,我希望Seam和他们不要牵扯太深,能够单独的配合JSF动作就可以了。我看到的第二篇出自IBM的文章让我消除了这种顾虑,上面明确的提出了你不需要使用EJB。按照文章中提到的方法,开始我的第一个Demo。在我的常识中,好的Framework,不仅仅功能强大,上手也应该是非常快,特别是出你的第一个hello world页面。但是Seam有点出乎我的意料,虽然第一个页面的出现非常顺利,但是后台的Error一直连续不断,看看都是和EJB和GTW相关的。于是去Seam的新闻组提出了我的疑问,有一个很热心的网友建议我使用seam-gen,并且告诉我此工具非常的强大。但是当我运行此工具的时候,起始的设置就要我选择JBoss的安装目录,然后让我选择RichFace,以及Hibernate方言之类,似乎用这个东西就注定了你必须使用JBoss,以及Hibernate。有点晕,有点怀疑Seam。虽然目前只是看了没有几个小时,但是我想我还是会继续研究它,但是对于很多人吹嘘的好,已经开始怀疑了。

0 Responses to "关于Seam,一些想说的"