Hibernate和IBatis对比

项目也做过几个, 使用IBatis就做一个项目, 基本上都是使用Hibernate, 也只是知道几点关于这两个框架的区别, 今天闲着没事干, 从网上找了几篇文章, 做了一个简单的整理。网上关于这两个框架的比较也很多, 只是自己想把别人的东西拿过来整理一下, IBatis和Hibernate的比较。(非原创)

Hibernate  VS  iBATIS

简介
Hibernate是当前最流行的O/R mapping框架，当前版本是3.05。它出身于sf.net，现在已经成为Jboss的一部分了。
iBATIS是另外一种优秀的O/R mapping框架，当前版本是2.0。目前属于apache的一个子项目了。
相对Hibernate"O/R"而言，iBATIS 是一种"Sql Mapping"的ORM实现。
Hibernate对数据库结构提供了较为完整的封装，Hibernate的O/R Mapping实现了POJO和数据库表之间的映射，以及SQL的自动生成和执行。程序员往往只需定义好了POJO到数据库表的映射关系，即可通过Hibernate提供的方法完成持久层操作。程序员甚至不需要对SQL的熟练掌握，Hibernate/OJB会根据制定的存储逻辑，自动生成对应的SQL并调用JDBC接口加以执行。
而iBATIS的着力点，则在于POJO与SQL之间的映射关系。也就是说，iBATIS并不会为程序员在运行期自动生成SQL执行。具体的SQL需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。使用iBATIS提供的ORM机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate 实现ORM而言基本一致，而对于具体的数据操作，Hibernate会自动生成SQL语句，而iBATIS则要求开发者编写具体的SQL语句。相对Hibernate而言，iBATIS以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。
二者的对比：
1．  iBATIS非常简单易学，Hibernate相对较复杂，门槛较高。
2．  二者都是比较优秀的开源产品。
3．  当系统属于二次开发,无法对数据库结构做到控制和修改,那iBATIS的灵活性将比Hibernate更适合。
4．  系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。在这种情况下iBATIS会有更好的可控性和表现。
5．  iBATIS需要手写sql语句，也可以生成一部分，Hibernate则基本上可以自动生成，偶尔会写一些Hql。同样的需求,iBATIS的工作量比Hibernate要大很多。类似的，如果涉及到数据库字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。
6．  以数据库字段一一对应映射得到的PO和Hibernte这种对象化映射得到的PO是截然不同的，本质区别在于这种PO是扁平化的，不像Hibernate映射的PO是可以表达立体的对象继承，聚合等等关系的，这将会直接影响到你的整个软件系统的设计思路。
7．  Hibernate现在已经是主流O/R Mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于iBATIS。
8．  最关键的一句话是iBATIS的作者说的：
If you are starting a new project and you're in full control of your object model and database design, Hibernate is a good choice of O/R tool.
If you are accessing any 3rd party databases (e.g. vendor supplied), or you're working with a legacy database, or even just a really poorly designed database, then an O/R mapper might not be capable of handling the situation. That's were an SQL Mapper comes in handy

结论:
Hibernate和iBATIS可以说是互相补充,共同发展的关系.具体你想用什么要看实际情况.如果看了上面的文字还是拿不定注意,那就Just to try it.实践是检验真理的唯一标准.鞋合不合适,只有试了才知道。

说明：本文转自：http://blog.csdn.net/hero272285642/archive/2008/04/25/2327887.aspx

 

选择Hibernate还是iBatis?
选择Hibernate还是iBATIS都有它的道理： 
Hibernate功能强大，数据库无关性好，O/R映射能力强，如果你对Hibernate相当精通，而且对Hibernate进行了适当的封装，那么你的项目整个持久层代码会相当简单，需要写的代码很少，开发速度很快，非常爽。 
Hibernate的缺点就是学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡取得平衡，以及怎样用好Hibernate方面需要你的经验和能力都很强才行。 
iBATIS入门简单，即学即用，提供了数据库查询的自动对象绑定功能，而且延续了很好的SQL使用经验，对于没有那么高的对象模型要求的项目来说，相当完美。 
iBATIS的缺点就是框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。 
我的建议就是： 
如果你的团队没有Hibernate高手，那么请用iBATIS，要把Hibernate用好，并不容易；否则你应该选择Hibernate，那样你的开发速度和代码简洁性都相当棒！ 
我觉得rails的ActiveRecord是平衡性做的最好的，避免了Hibernate的复杂性和学习HQL的成本，同时具备iBATIS即学即用的简单性。

说明：本文转自：http://robbin.javaeye.com/blog/24529

我为什么选择 iBatis而不是 Hibernate(对于正在选型的人的建议)
1. iBatis易于掌握。拿来文档看半天到两天就可以掌握了。 
Hibernate可能需要3倍以上的时间来掌握。 

2. iBatis更容易进行sql的优化。 
这个应该大家都有共识了。另外Hibernate生成的sql也实在是太难看了。鉴于有的朋友提到了sql不太重要。我想在这里强调一下我的经验，一般系统性能的瓶颈都在数据库上。所以这一点是iBatis非常重要的一个优势。 
3. iBatis 可以进行细粒度的优化
3.1 比如说我有一个表，这个表有几个或者几十个字段，我需要更新其中的一个字段，iBatis很简单，执行一个sql：UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用Hibernate的话就比较麻烦了,缺省的情况下hibernate会更新所有字段。当然我记得hibernate有一个选项可以控制只保存修改过的字段，但是我不太确定这个功能的负面效果。
3.2 我需要列出一个表的部分内容，用iBatis的时候，这里面的好处是可以少从数据库读很多数据，节省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ... 
3.2.1 一般情况下Hibernate会把所有的字段都选出来。比如说有一个上面表有8个字段，其中有一两个比较大的字段，varchar(255)/text。上面的场景中我为什么要把他们也选出来呢？ 
3.2.2 用hibernate的话，你又不能把这两个不需要的字段设置为lazy load，因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显出ibatis的好处了 
3.2.3 Hibernate还有一个方案，就是生成javabean/map/object[](感谢leelun/cjmm)，但是这样的话就可能会产生大量的多余class。map/object[] 的方式应该不错，我比较喜欢这种方式。 
3.3 如果我需要更新一条记录（一个对象），如果使用hibernate，需要现把对象select出来，然后再做update。这对数据库来说就是两条sql。而iBatis只需要一条update的sql就可以了。减少一次与数据库的交互，对于性能的提升是非常重要。 
4. 开发方面 
4.1 开发效率上，我觉得两者应该差不多 
4.2 可维护性方面，我觉得iBatis更好一些。因为iBatis的sql都保存到单独的文件中。而Hibernate在有些情况下可能会在java代码中保存sql/hql。 
5. 运行效率 
5.1 在不考虑cache的情况下，iBatis应该会比hibernate快一些或者很多（根据实际情况会有所不同）。 
当然iBatis也有比较大的缺点 
1. 不同数据库类型的支持不好，如果你要开发的系统是要在对中数据间移植，那可能用hibernate比较好。 

2. 缺省的cache支持不好，但是hibernate的cache支持其实也不是很好，而且很复杂。尤其是对于大并发量的应用。所以我更倾向于自己管理cache。

 

hibernate与ibatis比较的11大优势 
Hibernate在解决性能问题方面做得非常好。有了它的缓存机制，使用第三方缓存和数据库连接池，就较好的解决的性能问题。但这些还不够，hibernate给了开发者足够的自由，让开发者自己去控制性能问题。
学习了一段时间的ibatis，我觉得hibernate有着ibatis无法替代的优势。
1、开发者都知道，hibernate让我们以oo的方式操作数据库，这让我们看到了hibernate的强大之处，体验到操作数据的方便。但Gavin King说，hibernate最耀眼之处是hibernate的缓存机制，而不是以oo的方式操作数据库。Hibernate的缓存机制不外乎是一级缓存session，二级缓存sessionFactory，和第三方缓存如ehcache。也就是hibernate的最强大的地方是它的缓存，理解了这个才能真正的理解hibernate。缓存实在太难了，我至今未能真正理解。
2、可维护性：ibatis宣扬写sql语句，它将sql语句放进一个单独的xml文件，这种方式赢得了很多开发者的喜爱，一句话，方便维护。但hibernate同样具有这种功能，而且比ibatis更加强大。Hibernate的命名查询/命名参数查询，就是将hql语句放在一个单独的xml文件之中，它仍然让人们以面向对象的方式去操纵数据，这得到大量遵循 oo方式开发者的喜爱，而不用在以oo的方式写着代码的同时，然后再转变思维，用面向关系的方式去写那些sql语句。但hibernate不仅做了这些， 它的native sql查询方式，完全满足sql语句的偏爱者，它像ibatis一样，将sql语句放在配置文件之中。
3、性能：我坚信，hibernate性能问题不是问题。想想那么多大中小项目都在使用hibernate，你还怀疑hibernate的性能吗？spring整合hibernate之后，在真正性能瓶颈的地方，完全可以使用spring集成的jdbc，或直接写存储过程得了。但首先得确认，这实在是性能瓶颈的地方，我想，不应想当然的认为性能的问题，所谓的性能问题阻挠了很多人。我认为，性能的好坏无外是发送sql语句的多少而已。性能好，发送的sql语句少，性能差，就是发送大量的sql语句。Hibernate在解决性能问题方面做得非常好。有了它的缓存机制，使用第三方缓存和数据库连接池，就较好的解决的性能问题。但这些还不够，hibernate给了开发者足够的自由，让开发者自己去控制性能问题。
我认为开发者可以在以下几个方面自行调优：
a、在查询字符串中，应该总是使用jdbc的占位符？，或使用使用命名参数：，不要自查询中使用字符串值来代替非常量值。
b、Flush会影响性能，频繁刷新影响性能，尽量减少不必要的刷新。
c、Cascade策略，在几对几的关系，正确设置cascade策略，想清楚在操作对象A的同时是否需要级联操作对象B，比如在one to many的父子关系中，删除了父亲one，需级联删除子many，这时的one这端可设置cascade="delete"，这样在删除one时，会自动删除子，但对子的操作不会影响父。Cascade还有其他的属性值，只要设置正确，可提升性能。
d、lazy策略，正确设置延迟加载策略同样会提升性能，在one to many或many to many中，通常总应该延迟加载many的一方的到内存。设置了lazy="true"，首先发送sql语句，加载自己到内存，到需要时才加载级联对象；lazy="false",则会同时加载自己和级联对象到内存。
e、另外还有集合的性能(set、list、map、array)，都应正确设置。
f、正确使用第三方缓存，在读操作频繁写操作不多的情况，使用第三方缓存可大幅度提升性能，如ehcache的缓存策略有：read-only，read-write和notstrict-read-write。
f、 随着hibernate新版本的发布，和技术的发展，我相信hibernate的性能会越来越好，所有性能不是不使用hibernate的原因。
4、hibernate不仅仅作为持久层的orm框架存在，它除了dao层的持久化操作外，还有很多。
在注解annotation已经走向主流的今天，hibernate 迅速响应，让xml部署描述符成为可选的。Hibernate annotation对大字段的处理只是一个@Lob就搞定了。
hibernate search对Lucene进行了轻量级的封装，全文检索变得非常简单。
Hibernate validator被认为是最合理的验证方式，将验证策略直接附在贯穿各层的领域模型domain上，不再需要哪些web框架的xml方式的验证，代码中不再出现大量的非空/null的判断。
5、jbpm，Jbpm业务流程引擎的持久层采用hibenrnate来实现，要想使用jbpm，hibernate是必须的。我想，业务流程管理无比重要，在SOA迅速发展的今天，如果实施SOA项目，业务流程管理是必然和必须的。因为soa就是业务和it技术的融合，是业务流程管理和it基础架构的融合。在soa中，业务管理是第一位的，这需要相应的技术来实现该业务流程管理。开源领域的jbpm我想会是首选。所以，为了将来有可能实施soa项目，为了实现soa的业务流程管理，应该使用hibernate。
6、大家都知道，hibernate将ejb2时代的实体bean赶进了历史，而ejb3的jpa标准也只不过是hibernate的子集而已。jsr规范请求的威力是巨大的，没有各种jsr规范请求，就不会有各种应用程序框架，各种应用程序框架只是那些jsr规范请求的实现者。jpa作为持久层的规范标准，引导持久层orm框架的方向，jpa同样以面向对象的方式操作数据库，而不是写sql语句。规范标准都完全orm，不写sql了，你还有理由不跟着它吗？
7、Spring+hibernate+范型+可变参数，这是一个非常强大的组合，对应普通的crud操作，你不再需要重复写那些烦人的相似的dao层和manager层的代码，仅仅需要写一次，就完成了所有大量的crud操作。Ibatis尽管也支持范型，但始终没有hibernate支持的好
8、Jboss，hibernate是jboss的项目，jboss的所有项目的持久层都采用的hibernate，要知道，jsr规范组的专家们大多数是来自jboss的，在一定程度上说，jboo引领着java的发展方向。使用hibernate，跟着jboss，不偏离java的发展方向。
9、Gavin King，我最崇拜的偶像，他不仅发明了强大的hibernate，还搞出了同样强大且优雅的web2.0应用程序框架seam。他是ejb3.0专家组成员之一，是jpa规范请求的领导者，他java领域最有发言权、最权威的领袖人物之一。现在，他领导web bean的，jsr299的发展，web bean规范的制定，全球软件巨头如ibm、oracle、bea和apache没有一个反对，纷纷响应。Web bean，想象起来，实在太美好了，完全的松耦合和强类型，所有的应用组件生活在一个应用组件上下文context中，相互合作。那时将不再有各种各样的上下文环境，不再有struts2的ActionContext，不再有spring的ApplicationContext，不再有hibernate 的session，不再有持久化上下文，不再有事务上下文，不再有安全上下文，所有组件生活在一个大家庭中，大家其乐融融，实现天下的大和平。
10、 osgi，我认为现在最值得学习的一个技术，有了osgi，实现真正的多模块开发，改变传统的开发方式。现在，已经有了hibernate osgi，spring dynamic modul(osgi),struts 2同样实现了对osgi的支持。目前，eclipse是基于osgi开发的，ibm的websphere v6.1，bea的所有产品都重构在osgi上，spring的应用服务器同样基于osgi，在EclipseCon2007上，osgi成为了主要的话题。Osgi受到如此的待遇，一点不奇怪，因为他具有无比强大的功能，改变传统的软件开发方式。Osgi采用树设计模式，将一个项目分成多个模块(bundle)，每个模块单独部署，单独运行，说白了，就是将一个工程分成许多的插件，每个插件单独开发，重复使用，实现完全的即插即用。太令人激动了。如果公司的软件开发基于osgi，将会有大量的重复使用的osgi bundles，公司将会积累大量的无形资产，软件开发将会越来越快。而ibatis现在还没见到对osgi的支持。
11、hibernate的社区非常繁荣，ibatis则相对平静。
综述，hibernate还有很多优秀的特点，只是我们不知道。Hibernate与ibatis，就像大家闺秀对小家碧玉，大家闺秀不仅具有小家碧玉的全部，而且知名度更高，更受尊敬，更受人追捧，更有发展前途。小家碧玉尽管也很有魅力，但始终比上大家闺秀。
Hibernate所做的不仅仅是dao层的持久化工作，而ibatis恰恰如此。
选择hibernate，选择orm的王者，选择更全面的工作体验，选择更高效的工作方式，选择更多的利润；选择Gavin King，跟着领袖走；选择jboss，追随开源的潮流，不偏离java的发展方向。
一切都不是借口。一切都在发展，hibernate会越来越好。

本文来自:http://blog.sina.com.cn/s/blog_4adc4b0901010kcx.html

 

Hibernate与IBatis的优缺点及可行性分析

1.优点
简单：
易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。
实用：
提供了数据映射功能，提供了对底层数据访问的封装（例如ado.net），提供了dao框架，可以使我们更容易的开发和配置我们的dal层。
灵活：
通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能，或许更多。
功能完整：
提供了连接管理，缓存支持，线程支持，（分布式）事物管理，通过配置作关系对象映射等数据访问层需要解决的问题。提供了dao支持，并在dao框架中封装了ado.net，Hibernate和datamapper.增强系统的可维护性：通过提供dal层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。sql和代码的分离，提高了可维护性。
2.缺点
滞后性：
还没有明确对。net2.0的支持。最新版本在2.0下编译可以，但有些单元测试不能通过。
不成熟，工程实践较少：ibatisnet在实际项目中的使用较少。只是理论上可行。
半orm，工具支持较少：需要我们自己写sql，并且。net下还未发现可以自动生成业务层类和配置文件的工具，这点和Hibernate不一样，Hibernate会为我们的数据库直接产生sql，并有一些辅助工具。因此使用ibatis比Hibernate要多做一些工作。
3.可行性
没有最好的框架，只有最适合的框架。存在的便是合理的，它存在就说明有它存在的道理。但它未必为我们存在。所以选择一个框架最主要的是看它对你有没有意义，意义有多大，是不是比其他框架带给你的好处要多。没有绝对的优点也没有绝对的缺点，重要的是看在什么情况下讨论。
上面说了部分的ibatis的优点和部分缺点。这些优点从理论上证明ibatis对任何数据持久层都合适，但未必是最好的选择。下面对上面的优缺点分别从两方面讨论。
简单：
我们都喜欢简单，简单意味着学习成本低，使用中出错的可能性低。同时，简单的东西一般来说功能不够强大。反过来，复杂的东西学习成本高，用起来不方便，并且团队没有很强的技术实力，一般不要使用。
实用：
解决了项目中需要解决的问题，这是任何实际工程中采用的框架和工具都应具有的性质，否则就不要拿到实际项目中来。
灵活：
灵活有两层意思，一种是简单易扩展，另一种是功能强大提供了很多选项。ibatis属于前者，Hibernate属于后者。两者各有优缺点。
功能完整：
ibatis的功能完整也是相对的，比我们自己开发的框架应该完整，但对比其他框架肯定也有一些解决不了的问题。
增强系统的可维护性：利用ibatis可以做到sql和代码分离，可以设计出一个清晰的数据访问层（dal）。但项目架构是否科学合理，是否以维护，关键 不在ibatis，因 为它只是一个数据层框架。但是我们也不得不清楚，要想发挥ibatis的优势，我们需要做一些额外工作，比如最好设计dao接口，需要将业务层实体和对实 体的访问放在不同的工程中，同时需要维护xml配置文件。
滞后性：
ibatis组现在还没有提到要支持。net2.0，很多人在。net2.0下使用ibatis都出现了问题。所以如果要使用。net2.0开发，ibatis不是一个好选择，还需要等待。
不成熟：
开源的东西很难说成熟，但一般比我们自己写的框架要成熟。由于我们可以拿到他的源代码，所以关键在于我们能否驾驭它。
半orm，工具支持少：
这注定了ibatis不能从本质上提升开发效率，我们需要自己写sql，写实体类，写配置文件。但这也是它优越的地方，它没有为我们做的他多，所以我们就 有更多的施展空间。而且它非常适合那些并不能完全控制数据库的系统和需要利用数据库本身提供的高级特性的统计查询系统的开发。
使用ibatis需要自己写sql，由于我们的sql不可能完全符合sql标准，比起Hibernate产生的sql来，可移植性差。不过由于我们更改 数据库的可能性较小，对我们来说sql符合标准以便可以在迁移到不同服务器时代价最小并不是十分必要的。另一方面，Hibernate虽然可以屏蔽很多 数据库间的不同，但是却很难利用某些数据库的高级特性，比如oracle的分析统计函数。
Hibernate不适合数据库模式不规范，约束不完整，需要大量复杂查询的系统，同时Hibernate的学习成本较高，完全掌握Hibernate也较困难，风险较大。
自己写框架未必比ibatis的好，稳定，强大和可扩展。而且自己开发框架也需要较大的工作量。
如果使用dotnet并且要选一个数据层框架，而系统中有相当一部分较复杂的sql，或数据库设计不合理，脏数据多，对性能和资源要求严格，ibatis是一个比较不错的选择。他的那些缺点并不是致命的，而且也是有一些解决方案的。尤其是，当选用了ibatis的dataaccess作为dao框架时，我们可以同时使用Hibernate，ado.net和datamapper（ibatisnet的核心组件），那样将会使风险降到最低，并且整个系统的框架比较合理。
另外，利用ibatis可以统一编码风格，节约开发成本，大家不会再把精力浪费到分页 连接池 主键生成等地方了，可以集中精力进行业务组件的编写。
综上：很多时候我们要在是自己开发框架和选用第三方框架和选用什么样的框架问题上进行综合考虑。考虑的标准当然是项目的当前情况和我们希望达到目的的一个平衡。
ibatis只是封装了数据访问层，替我们做了部分的对象关系映射。但我们的代价是必须要写xml配置文件，相对于Hibernate我们还要写很多 sql.Hibernate通过工具直接从数据库模式生成实体类和基本的配置文件，而且大部分情况下不需要我们写sql，会较大的提升开发效率。但这些也 有很多的局限性，尤其是对环境的要求较高（数据库设计，对象设计，团队的协作等）。
个人感觉ibatis对项目比较有意义的地方在于它小巧灵活，可扩展，封装了数据访问层（事务，缓存，异常，日志），并提供了dao框架支持。
利用ibatis我们可以做到代码和sql的分离，只要sql能够解决的问题，ibatis就能帮我们较容易的解决，同时也使我们的项目对某一框架的依赖性变小（因为ibatis是非侵入性的）。这将极大的降低项目风险，减少解决复杂问题的时间，使项目的维护变得简单。
ibatis对于应用的修改，调试，扩充和维护将会变得容易自然。修改时，我们主要修改的是代表模型的实体对象，xml配置文件中的sql，和/或配置文 件的resultmap（很多时候是不需要的）。同时，sql和代码分离，我们不用在代码的stringbuffer的append方法之间寻找需要修改 的sql.配置文件中的sql便利了我们的调试和对sql的评审及以后的sql重用。
利用一些框架在前期一般会拖慢开发效率。因为我们需要付出学习成本，很多时候，使用框架需要写很多配置文件，在使用不熟时开发速度较慢；同时利用框架往往 使系统代码量增大，比如model1和model2模型，开发效率应该还是model1快，四层的架构肯定比两层的代码量大。但对于中后期开发和维护将会极大的提高效率。
利用一些较完全的开发框架和代码生成工具，在前期会较大的提高开发效率，但在后期常常会拖慢进度，并有可能成为以后维护的梦魇。比如torque生成实体类和其对应的sql，虽大幅提高了效率，但修改负担较大。
比较理想的开发方式是使用简单框架结合简单的代码生成工具。框架提供系统的基础服务，并规范开发。框架一方面提供了开发中某一方面的开发基础支持，比如数 据访问层，事务，日志，公用类，异常等。另一方面，也为开发定义了模式，定义了系统的基本轮廓。同时，通过简单的代码生成工具生成部分低级的代码。比如通 过工具从数据库模式生成实体类。这些类生成后我们可以自由修改。
Hibernate是十分强大，比较完善的orm框架，不过这是它的优点也是它的缺点。J2EE系统是否采用Hibernate3，是一个需要认真评估的问题。
要想Hibernate工作的好，数据库的设计必须好。同时对于复杂的数据操作同时需要使用sql，Hibernate3对于直接使用sql的支持比Hibernate2要自然，这一点是可以接受的。
Hibernate比较复杂，功能强大而灵活，要用好Hibernate确实不是很简单，当然spring框架提供了对Hibernate的封装，使Hibernate的使用变得简单了点。
可以说ibatis在任何系统里都适用，但未必是最好选择。不过ibatis提供的思路是我们应该仔细考虑的。