Java企业应用系统框架的比较与选择Word格式文档下载.docx
《Java企业应用系统框架的比较与选择Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《Java企业应用系统框架的比较与选择Word格式文档下载.docx（16页珍藏版）》请在冰点文库上搜索。
采用框架开发的企业应用具有必须继承或依赖目的需求，使用它几乎能解决企业级应用涉及到的所有问题，相应的基于
业务逻辑组件层和持久层。
最后针运算等
框架也是一
分布式
EJB
充分考虑到了顶级大型项
访问权限以及
安全
容器的特点。
容器能够很好的处理系统性能、事务机制、框架进行开发能保证企业应用平滑发展，而不是发展到一种规模就重新更
EJB个功能复杂的重量级框架。
J2EE1.4标准规定的EJB2.1框架缺少设计且实现起来有些过于复杂。
当前J2EE5.0的新规范提出的EJB3.0的目标就是简化开发[1]，借鉴了一些基于POJO的思想，它相对于EJB2.1中两个重要的变化分别是：
一是使用了Java5中的程序注释工具，注释取代了过多的XML配置文件并且消除了严格组件模型需求；
二是采用了基于Hibernate和TopLink思想的模型。
O/RMapping
J2EE5.0的新规范中定义企业应用三个层次的标准实现为：
表现层采用JSF（JavaServer
Face），JSF的开发流程的核心是事件驱动，组件和标签的封装程度非常高，很多典型应用已经不需要开发者去处理http。
整个过程是通过IoC（依赖注入）[2]来实现的；
业务组件层采用EJB3.0的SessionBean。
EJB3.0允许开发者使用藕合松散的组件来开发应用。
这些组件通过自己发布的商业接口来耦合，不必像EJB2.1规范定义的那样一个Bean必须遵守的严格的组件模型，每一个EJB类必须从某一种抽象类中继承，并为容器提供了回调的钩子；
持久层采用EJB3.0实体Bean持久化模型，吸收了Hibernate的一些思想采用O/RMapping
模式，EJBQL也有许多重要的改变。
2、基于POJOs的轻量级框架
在基于POJOs轻量级框架上开发的应用程序无需依赖于Java企业应用三个层次的轻量级框架技术分别都得到了一定的发展，如下：
目前比较流行的开源表现层框架主要有不同的是，它是基于组件，而不是面向脚本语言（比如定义文件（以XML模板、一个决方案也不少，框架是一个基于现bean的装配，的能力。
Spring
容器可独立运行，对应于
应用框架框架，
这三个层次流行的框架
Struts
与Spring
）的，组件是由一个
使得它可以很容易的实
TapestryVelocityIoC
和
TapestryJAVAJ2EE
。
和但是它不具备处理应用分布式
的构架。
采用
类构成的；
业务组件层轻量级解服务的可重用业务和数据访问对
、Hivemind（面向方面编程）
JSP
）、一个
AOP
的格式
HTML
[3]
包括IoC提供了简洁的的核心要点是：
支持不绑定到特定
Spring
等。
并据此实现事务管理等，
但是目前使用最为广泛的还是
和
Spring象。
这样的对象可以在不同J2EE环境（Web或EJB）、独立应用程序、测试环境之间重用；
持久层框主要有Hibernate和各种JDO产品，以及iBATIS。
Hibernate是一个开源的O/RMapping框架，它对JDBC进行了非常轻量级的对象封装，可以应用在任何使用JDBC的场合，可以在应用EJB的J2EE框架中取代CMP，完成数据持久化的重任。
iBATIS是一个简易的SQLMap工具，它是将手工编写的在xml配置文件中的SQL语句映射成Java对象。
．
对应于三个层次的框架比较、表现层框架比较1框架由设计模式不再是某一种表现层框架的特点而是这几种框架的共性。
StrutsMVC很容易找到很多现成的开源功能标非常活跃，社区于出现时间早，所以使用相对广泛，它的以及框架类的限但是它的组件在页面中显示的粗粒度，签以供使用以及样例程序可供参考。
制在很多情况下会表现得过于死板，给表示层的开发会带来一些额外的代码开销。
JSF在很大程度上类似Struts，只是JSF的组件概念没有象Struts那样必须继承ActionForm的限制，JSF在事件粒度上要比Struts细腻。
JSF有的另外一个优势就是其身后有Sun公司和其他的一些大公司的支持。
Tapestry是一个完全组件的框架，Tapestry的组件可以被套嵌并包裹其它组件，因此可以组合形成一个更大的组件或逻辑页面。
组件的行为模式为Web页面编程提供了很大的方便，事件处理也方便很多。
所以，如果做一个对页面要求灵活度相当高的系统就可以考虑选用Tapestry。
表1三种框架的表现层功能技术细节比较
2、业务组件层框架比较
EJB2.1框架有些过于复杂了，有如下缺点：
①EJB模型需要建立许多组件接口和实现许多不必要的回滚方法；
②EJB的部署描述复杂而容易出错；
③开发人员不能脱离EJB容器测试。
对于以上缺点JCP（JavaCommunityProcess）制订
的EJB3.0标准框架做了相应的改进，该框架为所有主要的J2EE厂商支持。
EJB3.0两个框架结构都有一个共同核心设计理念：
将中间件服务传递给耦合松散的EJB3.0框架与应用服务器高度整合，服务整合代码也包装在一个标准接口后面。
框架一方面有成熟的EJB容器支持，基于EJB框架的企业应用性能优良；
另一方面器设计因为考虑了多方面的功能，所以在其内核上总是会显得臃肿，这也是一种重量表现。
不需要的东西存在肯定会影响效率，EJB不能根据项目需求对可配置式的切割。
Spring框架处于应用服务器和服务库的上方，开发者。
它与应用服务器整合的能力相对EJB3.0体现了它优于EJB3.03、持久层框架比较
容器管理持久性（CMP）是对EJB中EntityBean性模型过于复杂并且存在基础缺陷[3]。
EJB3.0用与Hibernate类似的机制。
Hibernate相对而言其基本优势如下：
和。
POJOs
容器进行EJB2.1
EJB并暴露于应用
持久层针对
EJB2.1
进行持久性管理的方式。
整体包括框架模块的可分离配置的缺陷做了相应改进，采
服务整合的代码属于框架，
要弱。
但是
2EJB
框架的具体细节比较
的灵活性。
表．
SprinEJB容
持久
①Hibernate使用Java反射机制而不是字节码增强程序来实现透明性；
②Hibernate的使用简单；
③映射的灵活性很出色，它支持各种关系数据库，从一对一到多对多的各种复杂关系。
Hibernate也有一些缺点，它限制所使用的对象模型（例如，一个持久性类不能映射到多个表）。
使用iBATIS提供的O/RMapping机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate实现O/RMapping而言基本一致，而对于具体的数据操作，语句。
相对SQL则要求开发者编写具体的iBATIS语句，而SQL会自动生成Hibernate
Hibernate等“全自动”O/RMapping机制而言，iBATIS以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。
作为“全自动”ORM实现的一种有益补充，iBATIS的出现显得别具意义。
企业应用系统框架选择
设计和性能是实际框架选择的两个基本点，善于平衡才是框架选择的主要宗旨。
轻量级框架和重量级框架解决问题的侧重点是不同的。
轻量级框架侧重于减小开发的复杂度，相应的它的处理能力便有所减弱不具备分布式处理能力），比较适用于开发中小型企业应用。
采用轻量框架一方面因为尽可能的采用基于POJOs的方法进行开发，使应用不依赖于任何容器，这可以提高开发调试效率；
另一方面轻量级框架多数是开源项目，开源社区提供了良好的设计和许多快速构建工具以及大量现成可供参考的开源代码，这有利于项目的快速开发。
例如目前Tomcat+Spring+Hibernate已经成为许多开发者开发择。
随着可供选择的框架层出不穷，开发者可以根据需要对应于企业应用三个层次的轻量级框架选择，本文第2节的内容可供选择参考。
而作为重量级框架系结构中，一切与基础结构服务相关的问题和底层分配问题都由应用程序容器或服务器来处理，且EJB容器通过减少数据库访问次数以及分布式处理等方式提供了专门的系统性能解决方案，能够充分解决系统性能问题。
（如事务功能弱、
J2EE
中小型企业应用偏爱的一种架构选
框架则强调高可伸缩性，适合与开发大型企业应用。
在
体
轻量级框架的产生并非是对重量级框架的否定，甚至在某种程度上可以说二者是互补的。
轻量级框架在努力发展以开发具有更强大，功能更完备的企业应用；
而新的EJB规范EJB3.0则在努力简化J2EE的使用以使得EJB不仅仅是擅长处理大型企业系统，也利用开发中小型系统，这也是EJB轻量化的一种努力。
对于大型企业应用以及将来可能涉及到能力扩展的中小型应用采用结合使用轻量级框架和重量级框架也不失为一种较好的解决方案。
总结．
目前适用Java企业应用的系统框架可谓百花齐放，各种框架都有长短，选择应用系统框架时不可盲目的追求流行，首先需要明确所要实现的应用系统的系统处理能力需求，然后在熟悉比较各种框架细节的基础上从设计以及开发效率方面进行考虑。
本文旨在为系统框架选择提供一个参考，限于篇幅本文只对其中的几种框架做了比较，开发者可以根据需要对更多其他框架细节进行比较。
升级会员 