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. 将本来应该代码化的逻辑设置化，增进了堕落的机遇以及特另外承担。 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
