浏览 8690 次
|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-09-25
1． 什么是seam
根据JBOSS官方网站上的介绍,seam是一个JAVA EE 5平台的轻量级开发框架,JAVA EE 5平台下有那么多的框架我们为什么还需要一个在JAVA EE5 规范之外的seam框架呢?我们把seam看作一个原本应该包含在JAVA EE规范当中确没有被加入的框架.它为所有企业及开发中用到的组件提供一个统一的和谐的编程模型,它简化了基于状态的应用共和业务处理过程驱动的应用程序开发.
这篇文章中我将会向大家介绍seam是如何简化企业级应用开发的,我会使用几个web应用程序作为我们的讲解用例,但是在开始研究代码之前,我首先说明一下seam都做了些什么和seam的核心设计理念,这些内容将会帮助你更好的理解这篇文章的内容.
1.1． 黏合和增强JAVA EE规范下的各种技术
EJB 3.0 和 JSF 1.2 是JAVA EE5 平台下最为核心的技术.EJB3是一个轻量级的,基于POJO的开发框架,它主要着眼与业务处理和数据持久化,JSF是一个面向组件的MVC web开发框架,大多数JAVA EE 5平台下的应用都使用EJB处理业务层和数据持久层,使用JSF技术处理展示层,但是虽然EJB和JSF两种框架所提供的服务是互补的,但是由于他们被设计成两个独立的框架,所以他们始终无法完美的整合到一起,比如EJB3使用注解而JSF确使用XML,EJB3的组件和JSF的组件在框架级别上是无法感知到对方的.如果想是JSF和EJB3一起工作你不得不编写façade对象来把业务层和展示层连接到一起,这些技术间的黏合正是seam所提供的能力.seam把你从编写façade对象中解脱出来,seam提供了一个和谐的,基于注解的EJB3-JSF黏合剂,使用几个简单的注解可以使seam中的ejb3直接作为JSF页面的backing bean,甚至直接响应页面上的动作事件.seam使开发者可以为所有组件使用带有注解的POJO,和其它web开发框架相比,开发同样的功能使用seam更为简单而且需要写更少的代码,包括java和XML代码
Seam同时也简化了实现JSF特殊任务的能力,比如,JSF的一个最主要的抱怨就是JSF依赖于HTTP POST,这样为JSF页面添加书签就变的很困难,使用seam创建一个restful风格的页面确是非常容易的事情,seam提供了一组标签和注解来增强JSF页面的功能.,同时,seam增强了EJB3组件为seam POJOs ,和把展示层的状态扩展到了业务层,此外seam还整合了许多其它的顶级框架,比如JBPM,iText,Spring等,seam不是简单的把他们连接到一起,而是向增强EJB3+JSF一样来增强他们.
1.2． 为ORM设计的WEB开发框架
对象-关系型映射被广泛应用在企业级开发当中,但是当前大多数web开发框架都不是为ORM设计的,他们没有从一个请求开始直到生成响应的整个过程中一直维护数据持久上下文,这将导致很多数据持久层的错误,比如使用hibernate你就不得不在展示层使用opensessioninviewfilter来支持延迟加载特性,同时这样的web开发框架会产生大量丑陋的DTO.
使用seam你再也不用写那些丑陋的DTO,同时你可以随意在程序中使用延迟加载而不用任何特殊配置,而且ORM的性能也会得到进一步提高,(request->response之间seam维护的数据持久上下文是一个天生的缓存).
此外,seam把ORM层,业务层和展示层完美整合到了一起,这就意味着我们可以在展示层直接呼叫持久层服务,为页面表单使用持久层的数据校验注解和把数据库异常信息直接显示到展示层的页面上
1.3． 为有状态应用开发而设计
Seam是为有状态应用程序而设计的框架,web应用程序天生就是多用户的,而商业化的程序天生就必须有状态和事务管理功能.可是大多数web开发框架更侧重于无状态的web应用程序开发,你不得不小心的处理http sesssion来维护用户的状态,这样你的程序不但会被这些与业务逻辑不相关的丑陋代码打乱而且可能还会带来性能问题.
Seam中所有应用程序基础组件都是天生有状态的,他们比HTTP session更加容易使用,因为seam会自动维护他们的状态.在seam应用程序中再也不用写那些操作session来进行状态维护的丑陋代码了----只需要用注解表示出组件的存取范围,生命周期方法和其它状态属性即可,这样你就可以更加专著与你的业务逻辑,与http session相比Seam的有状态组件提供了更加出色的可调节性.比如说你可以在同一个http session当中包含多个seam会话,每一个会话都表示一个业务处理流程的状态.
此外,持久层的缓存和事务会自动连接到seam的状态管理上,seam自己在内存中持有数据库的update数据,只有在一个业务会话结束的时候数据才会被提交到数据库中.在复杂的业务逻辑中这种内存式的数据缓存策略极大的减少了数据从数据库的装载量.同时也维护了业务处理的完整性.
把我门以上提到的所有内容综合起来看,seam通过整合JBPM在web应用程序的状态管理上迈出了一大步,你可以为组织架构中的不同人指定不同的工作流程,使用这些不同的工作流程来驱动你的web应用程序,而不是传统的基于页面事件和数据的web应用.
生命式上下文组件
在seam中每一个有状态的组件都有一个存取范围或上下文,比如说,一个购物车组件是在购物会话开始的时候被创建,在下订单会话结束后被销毁,因此,这个组件在整个购物过程会话中都是有存活的,只时候你只需要简单的在这个组件上使用seam注解,seam会自动维护这个组件的生命周期.
Seam提供了一些不同的状态上下文,从一个简单的请求到一个复杂的多页面会话,一个http session范围,甚至一个长时间运行的复杂的业务处理过程.
1.4． 支持web2.0
Seam专为web2.0提供了优化,他提供了多种方式的Ajax支持,从内制Ajax组件到为现有组件添加Ajax能力,到自定义可以直接从页面访问服务器上seam组件树的javascript库.seam提供了一个高级别的并发Ajax请求处理模型
Ajax应用的一个挑战就是数据库的负载量,一个ajax应用比一个不是ajax的应用发送的数据库请求要多的多,如果所有的ajax请求都由数据库来亲自处理那么数据库的压力会非常大,只是后维护在seam程序内存中的持久化上下文相当于一个内存缓存,它可以为长时间运行的复杂业务逻辑持有数据,从而缓解数据库服务器的压力.
同时,web2.0应用程序往往会使用复杂的数据模型,对于这些应用程序来说数据的延迟加载是至关重要的,否则一个简单的查询可能会导致整个数据库的数据被加载,到目前为止,seam是唯一一个完美支持web层数据延迟加载的web层框架.
1.5． 依赖DI的POJO服务
Seam框架之所以是一个轻量级的框架是因为它大量采用POJO作为服务组件,在seam程序中没有任何框架的特定接口或抽象类.这些POJO通过当前流行的DI进行组织,在这种设计模式下seam负责POJO的生命周期,当一个POJO需要另一个POJO时候只需要使用注解表示就可以了,seam负责依赖对象的实例化和注入等内容
Seam对DI进行了增强,支持双向注入,双向注入被广泛应用在seam应用程序中.
1.6． 例外情况配置
Seam应用程序开发之所以如此简单是因为它的一个关键设计理念—例外配置,例外配置是指seam框架本身为组件提供了一组默认行为,开发者只需要为那些不是默认行为的组件配置例外情况就可以了.
声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2007-09-25
一个新的技术刚出来时，总是光鲜照人，在选择时，不要被其自身所宣称的一系列优点所迷惑。冷静下来，除了列举一下优点之外，再列出一个缺点列表。看不到缺点分析，最好不要着急一头扎进去，搞不好，水面下面就是一个大石头。自己没时间去找石头了，希望有找到石头的人，列一下，呵呵
|
| 返回顶楼 | |
|
发表时间：2007-09-26
可惜用了jsf...
|
| 返回顶楼 | |
|
发表时间：2007-10-01
我现在感觉到非常痛苦用了seam，一个讨论的人都没有
|
| 返回顶楼 | |
|
发表时间：2008-06-03
seam很好啊！有什么不好的，资料讨论jboss官网上多的是，一票一票的~
|
| 返回顶楼 | |
|
发表时间：2008-08-01
用seam很不爽
资料少是一方面 和其他技术集成有很多现实的问题 而且不是很稳定 |
| 返回顶楼 | |
|
发表时间：2008-08-01
也不好调试
受到限制太多 |
| 返回顶楼 | |
|
发表时间：2008-08-02
大家说得都很宽泛，没有实质性的内容。
我用得就挺爽的啊。 用jpa的hibernate实现，能利用seam轻松实现客户端验证，能轻松利用seam内置的2个组件实现搜索和CRUD，很方便。 |
| 返回顶楼 | |
