Java 五大框架之间的对比
|
8 类型转换的对比：Struts 1 ActionForm 属性通常都是String类型。Struts 1使用Commons-Beanutils进行类型转换，每个类一个转换器，转换器是不可配置的;Struts 2使用OGNL进行类型转换，支持基本数据类型和常用对象之间的转换。 9 数据校验的对比：Struts 1支持在ActionForm重写validate方法中手动校验，或者通过整合Commons alidator框架来完成数据校验。Struts 2支持通过重写validate方法进行校验，也支持整合XWork校验框架进行校验。 10 Action执行控制的对比：Struts 1支持每一个模块对应一个请求处理(即生命周期的概念)，但是模块中的所有Action必须共享相同的生命周期。Struts 2支持通过拦截器堆栈(Interceptor Stacks)为每一个Action创建不同的生命周期。开发者可以根据需要创建相应堆栈，从而和不同的Action一起使用。 Hibernate优点 (1) 对象/关系数据库映射(ORM) 它使用时只需要操纵对象，使开发更对象化，抛弃了数据库中心的思想，完全的面向对象思想 (2) 透明持久化(persistent) 带有持久化状态的、具有业务功能的单线程对象，此对象生存期很短。这些对象可能是普通的JavaBeans/POJO，这个对象没有实现第三方框架 或者接口，唯一特殊的是他们正与(仅仅一个)Session相关联。一旦这个Session被关闭，这些对象就会脱离持久化状态，这样就可被应用程序的任 何层自由使用。(例如，用作跟表示层打交道的数据传输对象。) (3) 事务Transaction(org.hibernate.Transaction) 应用程序用来指定原子操作单元范围的对象，它是单线程的，生命周期很短。它通过抽象将应用从底层具体的JDBC、JTA以及CORBA事务隔离 开。某些情况下，一个Session之内可能包含多个Transaction对象。尽管是否使用该对象是可选的，但无论是使用底层的API还是使用 Transaction对象，事务边界的开启与关闭是必不可少的。 (4) 它没有侵入性，即所谓的轻量级框架 (5) 移植性会很好 (6) 缓存机制，提供一级缓存和二级缓存 (7) 简洁的HQL编程 Hibernate缺点 (1) Hibernate在批量数据处理时有弱势 (2) 针对单一对象简单的增删查改，适合于Hibernate,而对于批量的修改，删除，不适合用Hibernate,这也是OR框架的弱点;要使用数据库的特定优化机制的时候，不适合用Hibernate Hibernate和iBATIS 优缺点比较 (注意:iBATIS 是MyBATIS的前生，也就是1.0版本) Hibernate的特点： Hibernate功能强大，数据库无关性好，O/R映射能力强， Hibernate对数据库结构提供了较为完整的封装，Hibernate的O/R Mapping实现了POJO 和数据库表之间的映射，以及SQL 的自动生成和执行。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过Hibernate 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握， Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的SQL 并调用JDBC 接口加以执行。Hibernate的缺点就是学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡取得平衡，以及怎样用 好Hibernate方面需要你的经验和能力都很强才行，但是Hibernate现在已经是主流O/R Mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于iBATIS。 iBATIS的特点： iBATIS入门简单， 即学即用，提供了数据库查询的自动对象绑定功能，而且延续了很好的SQL使用经验，对于没有那么高的对象模型要求的项目来说，相当完美。iBATIS的缺 点就是框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据 库修改。当系统属于二次开发,无法对数据库结构做到控制和修改,那iBATIS的灵活性将比Hibernate更适合。系统数据处理量巨大，性能要求极为 苛刻，这往往意味着我们必须通过经过高度优化的SQL语句(或存储过程)才能达到系统性能设计指标。在这种情况下iBATIS会有更好的可控性和表现。 对于实际的开发进行的比较： 1. iBATIS需要手写sql语句，也可以生成一部分，Hibernate则基本上可以自动生成，偶尔会写一些Hql。同样的需求,iBATIS的工作量比 Hibernate要大很多。类似的，如果涉及到数据库字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。 2. iBatis 可以进行细粒度的优化 比 如说我有一个表，这个表有几个或者几十个字段，我需要更新其中的一个字段，iBatis 很简单，执行一个sql UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用 Hibernate 的话就比较麻烦了,缺省的情况下 hibernate 会更新所有字段。 当然我记得 hibernate 有一个选项可以控制只保存修改过的字段，但是我不太确定这个功能的负面效果。 例 如：我需要列出一个表的部分内容，用 iBatis 的时候，这里面的好处是可以少从数据库读很多数据，节省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE …一般情况下Hibernate 会把所有的字段都选出来。比 如说有一个上面表有8个字段，其中有一两个比较大的字段，varchar(255)/text。上面的场景中我为什么要把他们也选出来呢?用 hibernate 的话，你又不能把这两个不需要的字段设置为lazy load，因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出ibatis 的好处了。如果我需要更新一条记录(一个对象)，如果使用 hibernate，需要现把对象 select 出来，然后再做 update。这对数据库来说就是两条sql。而iBatis只需要一条update的sql就可以了。减少一次与数据库的交互，对于性能的提升是非常重 要。 3. 开发方面： 开发效率上，我觉得两者应该差不多。可维护性方面，我 觉得 iBatis 更好一些。因为 iBatis 的 sql 都保存到单独的文件中。而 Hibernate 在有些情况下可能会在 java 代码中保sql/hql。相对Hibernate“O/R”而言，iBATIS 是一种“Sql Mapping”的ORM实现。(iBatis 是将sql写在配置文件中的，而hibernate是自己生成的) 而iBATIS 的着力点，则在于POJO 与SQL之间的映射关系。也就是说，iBATIS并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。使用iBATIS 提供的ORM机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate 实现ORM 而言基本一致，而对于具体的数据操作，Hibernate会自动生成SQL 语句，而iBATIS 则要求开发者编写具体的SQL 语句。相对Hibernate而言，iBATIS 以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。 4. 运行效率 在不考虑 cache 的情况下，iBatis 应该会比hibernate 快一些或者很多。 Spring 框架的优缺点 Spring的优势不言而喻： 1. 提供了一种管理对象的方法，可以把中间层对象有效地组织起来。一个完美的框架“黏合剂”。 2. 采用了分层结构，可以增量引入到项目中。 3. 有利于面向接口编程习惯的养成。 4. 目的之一是为了写出易于测试的代码。 5. 非侵入性，应用程序对Spring API的依赖可以减至最小限度。 6. 一致的数据访问介面。 6. 一个轻量级的架构解决方案 缺点也显而易见 1. 中断了应用程序的逻辑，使代码变得不完整，不直观。此时单从Source无法完全把握应用的所有行为。 2. 将原本应该代码化的逻辑配置化，增加了出错的机会以及额外的负担。 （编辑：通化站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
