JBoss Seam被指是那种属于“Java EE 5.0的一个有着轻量级特质的框架”, 这究竟意味着啥? 难道说Java EE这个5.0自身原本就不是那种被定义为一套“框架之物”吗? 为啥明明处于官方规范范畴之外, 却还非得要有另外一个框架存在? 行, 那咱们就把seam当作是本应当被涵盖在Java EE 5.0里头的一个“因故丢失从而未曾包含进来的框架”。它处于Java EE 5.0框架的上层位置, 为所有那些处于企业Web应用当中的组件创设了一个具备统一性且易于让人理解领会的编程用的模型。它同样让基于状态的应用以及业务流程驱动的应用的开发变得轻而易举, 也就是说, Seam专注于开发者生产力与应用扩展性。1. 整合和强化Java EE框架Java EE 5.0的核心框架之中, EJB( )3.0 和 JSF( Faces)1.2占有重要地位, EJB 3.0简而言之下称EJB3, 是一种架构于带有业务服务以及数据库持久化的轻便POJO平常老式Java而形成的结构, JSF是一种依赖依据MVC(模型-视图-)形成的Web应用框架, 多数的Web应用都会含有具有业务逻辑的EJB3组件以及Web应用前端用以展示的JSF组件。EJB3与JSF虽说互补, 然而它们是依照各自理念所设计的独立框架, 举例而言, EJB3借助注解去配置服务, 而JSF运用的是XML文件, 进一步来讲, EJB3及JSF组件在框架层面彼此互不敏感, 要对EJB3和JSF进行整合, 开发者得手动构造对象比如: JSF支持bean, 把业务组件同Web页面以及样板代码也就是代码连接起来, 从而能够跨框架调用方法, 将这些技术粘合起来是Seam的职责之一。Seam破除了EJB3与JSF之间的人工层面, 它为整合EJB3以及JSF给出了一个统一的、基于注解的路径, 仅需个别简易注解, Seam里的EJB3业务组件便能直接用以支持JSF Web表单或者去处理Web UI事件, Seam让开发者把“同一类事物”——有注解的POJOs——应用到所有应用组件上。和借助别的Web框架所开展开发而形成的应用来进行比较, Seam应用的概念呈现出简洁的特性, 针对相同的功能而言, 在代码量方面于JAVA以及XML当中却需要更少的数量。要是缺乏耐心, 或者是期望能够实现快速预览, 想知晓一个Seam究竟能够简单到什么程度, 那么你能够先去瞧一瞧本文所描述的hello world这个示例。说说JSP方面困难的任务, Seam能够顺利完成。举个例子, JSF有个令人烦恼的问题, 那就是过度依赖HTTP POST。也就是说, 把一个被添加到书签里的JSF网页, 借助HTTP GET去进行访问是颇为艰难的。然而有了Seam, 创建一个REST网页是很简单的。Seam给出了一连串的JSF组件标签以及注解, 提升了“web友好”程度以及JSF应用的网页效能。于此同时, Seam把EJB3的组件模式拓展至POJO, 从web层直至业务层都存在状态上下文。更进一步来讲, Seam将一系列主要的其他开放源代码框架予以整合, 诸如jBPM、JBoss Rules又名、JBoss、JBoss等等。Seam不但能够把它们“有机结合”在一起, 并且能够如同整合JSF和EJB3那般强化原有的框架。位于Java EE 5.0底层区域部分的是Seam, 然而其应用并非仅仅限定于Java EE 5.0服务器, 一个Seam应用能够被部署在J2EE 1.4应用服务器之上以及其它服务器之上, 这就意意味着当下在进行Seam应用的时候是可以收获产品化支持的。1 1 2可能存在着这么一种误会, 觉得Seam只不过是把各类不一样框架串联到一起的另外那个整合框架。Seam给出了它自身所管理的状态方面知识间关系, 准许框架借助注解以及EL表达式跟其他框架来完成深度融合。融合的程序源自Seam开发者对于第三方框架的认知体验。2. 一个为ORM设计的Web框架当今企业应用里, 对象关系映射也就是ORM解决方案被广泛运用。然而, 多数当下的业务以及web框架并非是为ORM而设计的, 在从请求到来直至响应结束的整个Web交互生命周期中, 它们都不管理持久上下文。如此一来, 便引发出了包含可怕的情况在内的各类ORM异常, 还带来了像“数据传输对象DTO”这般丑陋的伎俩。Gavin King发明了Seam, 他还发明了在全球广泛运用的ORM解决方案, 为传承和弘扬ORM的最佳实践, Seam被重新设计, 有了Seam, 无需再编写DTO, 只需进行延迟加载, 由于扩展后的持久上下文恰似一个自然的高速缓存, 能减少与数据库的交互, ORM的性能便会得到极大提升。再者说, 鉴于Seam将ORM层、业务层以及表示层进行了整合, 所以开发者能够于表示层直接呈现ORM对象, 还能够把数据库验证注解应用到输入表单上, 并且能将ORM例外重新定向到定制的错误页面。3.专为有状态Web应用而设计Seam是专门针对有状态Web应用予以设计的, Web应用是天然的多用户应用, 电子商务应用天然同样是有状态且有事务的, 然而, 多数已有的Web应用框架是面向无状态应用的 , 开发者必须去操作HTTP会话对象用以管理用户状态, 和核心业务逻辑没有关系的代码不但会让你的应用变得混乱, 并且带来了一连串的性能问题。在Seam里, 全部的基础应用组件自然而然地具备状态。它们运用起来相较于HTTP更为简便, 这是由于它们的状态是由Seam公开进行管理的。在Seam应用当中没有必要去编写会引发麻烦的状态管理代码, 只需在其组件上对其作用域、生命周期方法以及其他状态属性作出注解, Seam便会负责其他事项。译者注指这些组件的生命周期Seam状态组件相较于HTTP会话而言, 在管理用户状态方面具备更优的表现。比如说, 你能够开展多个“会话”, 每个“会话”是由处于一个HTTP会话里的一系列Web请求以及业务方法调用共同组合形成的。进一步来讲, 于Seam里, 数据库缓存以及事务能够自动跟应用的状态接连起来。Seam会在内存当中自动留存数据库更新, 一直等到对话结束之时再提交至数据库。内存里的缓存能够极大程度减轻复杂状应用里数据库的负载。除去以上所提及的这些, Seam对开源的JBoss jBPM业务程序引擎予以支持整合, 这使得Web应用里的状态管理获得了极大提升。你当前能够针对一个机构里不同的工作人员, 像是客户、经理、技术支撑人员等等, 去制定工作流程, 借助工作流程来推动应用, 而非依靠用户界面事件处理以及数据库。4. 支持Web 2.0Seam针对Web2.0应用做了极为充分的优化, 它给予了AJAX也就是异步和XML, 作为用于增添网页交互的一项技术好多支持, 从内置“零”的AJAX组件, 到具备AJAX支持的JSF组件, 再到定制的库, Seam为处于浏览器端的对象给出了能够直接访问Seam服务器组件的路径, Seam提供了一个很先进的并发模型, 能够有效地管理源自同一用户的多个AJAX请求。就AJAX应用而言, 数据库负载持续增长是个极大挑战, 和非AJAX应用相比, AJAX应用会向服务器发送更频繁请求。一旦数据库要回应这些AJAX请求就会不堪重负。Seam里的状态持久上下文如同内存中的缓存, 能在会话开始到结束时保存信息, 最终有助于减少数据库交互。对于运用如网络交际站点那般处理和显示“用户”间关系的复杂关系模型来使用数据的Web2.0应用, 延迟加载对其ORM层十分关键, 不然简单查询就能级联加载整个数据库。像之前讨论的那样, Seam是目前唯一正确支持Web应用延时加载的Web框架。5.依赖双向映射的Pojo服务Seam是个带有“轻量级”属性的框架, 这是鉴于其把POJO也就是普通的Java对象用作服务组件。于应用范畴内, POJO未借助接口或抽象类去钩住组件。当然, 难题在于怎样让POJO进行交互以便构成此应用? 它们又怎样与容器服务比如说数据库持久化服务展开交互?Seam借助一种流行的、名为依赖注入(DI)的设计模式来联结所有POJO组件, 此模式下, Seam框架对所有组件的生命周期予以管理, 当一个组件要使用另一个组件时, 它通过注解向Seam表明此依赖, Seam依据应用当下状态获取这个依赖组件, 并把它注入到有需求的组件里。历经拓展依赖注入概念这一过程, 一个名为Seam的组件A, 能够构造出另外一个组件B, 并且, 会将此组件B“抛还”给Seam, 以此供其他组件像是组件C在后续进行使用。这种双向依赖管理, 甚至在简单的Seam web应用里都有广泛应用, 比如第二章的hello world那个例子。在Seam术语范畴内, 我们把这个称作“依赖双向映射”。6.非常规的配置译者注指以隐式映射为主题以显式映射为例外的配置方式使得Seam易于使用的主要设计原则乃是“非常规的配置”, 其思想在于为这些组件给予一系列默认行为, 开发者唯有在预期行为并非默认之时, 才去显式地配置组件, 比如, 当Seam把组件A当做属性注入至组件B时, 默认情况下, 组件A就会以组件B被注入的属性的名称来命名, Seam里还存在很相似的细节, 总的结果是Seam中配置元数据相较于其他Java框架要简单得多, 所以, 大多数的Seam应用能够通过一系列简单的Java注解来进行充分配置。开发者因减化后的复杂度而获取诸多益处, 最终, 相较于其他Java框架, 在实现相同功能时运用更少代码。7.避免滥用XML有可能你已然留意到, Java注解于阐述以及处理Seam配置元数据之际, 起着关键的作用。借由类似这般的设计, 促使框架更便于操作。J2EE发展早期时, XML曾被视作配置管理的“圣杯”。框架设计者把所有配置信息, 涵盖Java类以及方法名称都一股脑丢进XML文档, 却不考量给开发者带来的后果。反省过后, 发觉这是个严重失误。XML配置文档太过繁杂, 以至于重复。开发者得在代码已有信息基础上进行重复, 以此把配置和代码关联起来。这些重复致使应用容易出错, 比如说, 一个拼写有误的类名在运行时可能呈现为一个极难调试的错误。缺少合理默认配置又进一步让这个问题变得复杂起来。事实上, 在某些框架里, 有相当多数量的样板代码是以XML的形式存在的, 其数量有可能等同于甚至超过在实际项目应用当中JAVA代码的数量。对于J2EE开发者而言, XML的过度使用情况通常被称作是 ‘‘XML地狱’’。Java社区察觉到了XML被滥用的情况, 且已相当成功地用Java代码里的注解替换了XML, EJB3是Java官方标准化组织推动Java企业组件领域内注解运用的一项成果, EJB3对XML文档的使用具备完全的可选择性, 它朝着正确方向跨出了积极的一步, Seam把EJB3的注解吸纳进来, 为整个web应用扩充了基于注解的编程模式。然而, XML并非对配置数据全然没有益处。Seam的设计者察觉到, XML适用于那种指定页面流程, 或者定义业务流程的web应用当中。XML文档使得开发者能够集中管理整个web应用的工作流程, 与此同时, 还反对把配置信息分散在java源文件里。工作流程极少会与源代码相耦合, 所以在XML文档里, 并不需要重复录入已经存在于代码中的信息。8.为测试而设计Seam被重新设计是为了便于测试, 所有Seam组件都是注解过的POJO所以易于单元测试, 开发者仅借助常规Java new关键词构造实例接着在测试框架比如JUnit中运行任意方法, 若要测试多个Seam组件交互, 开发者逐个实例化各组件随后手动建立其相互关系即显式使用方法而非依赖Seam依赖注入功能。为了进行集成测试, 整个Seam应用是较为复杂的, 这是由于开发者必须要在特定的Seam容器当中运行应用。Seam会采用嵌入的轻量级容器去协助此类测试。在测试框架里, 开发者能够依照步骤来加载Seam容器, 随后运行测试。9. 卓越的工具支持对于一个将焦点放在开发者生产力方面的应用框架而言, 开发工具所给予的支持是极为关键重要的。Seam发布了一个以命令行为基础的生成器, 它被称作。它同Ruby - On - Rails里的生成器相类似, 它具备支持像从一个数据库生成完整CRUD应用这样功能的能力, 聪慧的开发者会借助像是“编辑/保存/在浏览器重新载入”这类步骤的方式、拥有测试支持的属性特点, 去改进web应用。然而更为关键的是, 所生成的项目并不依存于主流的Java集成开发环境, 比如说, 以及。具备了这个之后, 开发者能够随时开启入门之旅。