Hibernate or Mybatis
2016-05-14 15:37
330 查看
The biggest difference between Hibernate and the iBATIS DB Layer, or more specifically SQL Maps, is that Hibernate is an Object Relational Mapper, whereas SQL Maps (as the name implies) is an SQL Mapper. The difference?
An Object Relational mapper maps Objects to database entities directly. In the case of Hibernate, all SQL is generated based on those mappings. Custom SQL is handled via HSQL, an Object Oriented query language that basically facades real SQL.
A SQL mapper maps your Java Objects to real SQL statements. The SQL statements are not generated and the mapping is completely independent of the database entities and relationships.
In terms of features, I don’t know that they can be directly compared easily, as the products are really in different classes. The general rule of thumb is: 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.
However, 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. With an SQL Mapper, there are no restrictions to the mapping between the Object Model and the Data Model –even if either is poorly designed (which happens a lot in the real world –don’t forget about secondary databases that you might have to access…).
There are a lot more O/R mappers around, because they are quite simply one of the “holy grails” of computing. Examples include Hibernate, TopLink, CocoBase and all JDO implementations.
SQL Mappers are harder to come by, but really any embedded SQL system can be considered an SQL Mapper, including iBATIS SQL Maps, Oracle SQLJ, Forte 4GL Embedded SQL, Pro*C Embedded SQL etc. In the case of iBATIS SQL Maps, you can think of it as SQL embedded in XML.
In terms of performance, the old SQL Mappers embedded in compiled languages are probably the fastest raw performing solutions because they are fully compiled. O/R mappers have to do a lot more work and usually involve reflection. iBATIS SQL Maps in this respect is more like an O/R mapper, as it is not fully compiled and uses reflection (however full compilation is not entirely out of the question).
As for who is actually the fastest, I don’t believe anyone knows for sure. Everyone has a different answer. If you ask some vendors, they’ll tell you that their product is N times faster than raw JDBC without caching (starts with “c” ends with “ocobase” –not likely). :-)
I believe that the performance of these frameworks will largely depend on how you use them. If you have a very straight-forward CRUD app, with Table-Class mappings, then an O/R mapper has a number of advantages in terms of simplicity and performance. However, if you have a complex/poor/large/etc. database model beyond your control, then an SQL mapper might be the only solution that works for you.
Generally an O/R mapper can create much more efficient mappings and cache strategies because it “knows” more about both the object model and the database. However, if it came down to a complex data transformation (say, flattening a relational parent/child tree), then an SQL mapper could likely do it much faster because it could take advantage of more efficient SQL. Generally you’ll have more control over the exact processing with an SQL Mapper, and therefore it offers more opportunity for tuning complex queries.
My suggestion: Try more than one. Do a couple of proofs of concept for your project and implement a deep “vertical slice” that you can test performance with. Every project will be different. For some, you’ll want Hibernate, others you’ll want iBATIS SQL Maps, others still you’ll want to use TopLink or maybe even raw JDBC.
For this reason, I think it’s more important and useful to learn how to evaluate and test these tools quickly and effectively; and it is less important to learn only one of them exclusively or even very well. Practice and get better at making good decisions, and worry less about finding “the grail”.
In the end the choice is yours and nobody can tell you what the right one is. Trust only yourself, draw your own conclusions and do lots of testing!
Clinton Begin
An Object Relational mapper maps Objects to database entities directly. In the case of Hibernate, all SQL is generated based on those mappings. Custom SQL is handled via HSQL, an Object Oriented query language that basically facades real SQL.
A SQL mapper maps your Java Objects to real SQL statements. The SQL statements are not generated and the mapping is completely independent of the database entities and relationships.
In terms of features, I don’t know that they can be directly compared easily, as the products are really in different classes. The general rule of thumb is: 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.
However, 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. With an SQL Mapper, there are no restrictions to the mapping between the Object Model and the Data Model –even if either is poorly designed (which happens a lot in the real world –don’t forget about secondary databases that you might have to access…).
There are a lot more O/R mappers around, because they are quite simply one of the “holy grails” of computing. Examples include Hibernate, TopLink, CocoBase and all JDO implementations.
SQL Mappers are harder to come by, but really any embedded SQL system can be considered an SQL Mapper, including iBATIS SQL Maps, Oracle SQLJ, Forte 4GL Embedded SQL, Pro*C Embedded SQL etc. In the case of iBATIS SQL Maps, you can think of it as SQL embedded in XML.
In terms of performance, the old SQL Mappers embedded in compiled languages are probably the fastest raw performing solutions because they are fully compiled. O/R mappers have to do a lot more work and usually involve reflection. iBATIS SQL Maps in this respect is more like an O/R mapper, as it is not fully compiled and uses reflection (however full compilation is not entirely out of the question).
As for who is actually the fastest, I don’t believe anyone knows for sure. Everyone has a different answer. If you ask some vendors, they’ll tell you that their product is N times faster than raw JDBC without caching (starts with “c” ends with “ocobase” –not likely). :-)
I believe that the performance of these frameworks will largely depend on how you use them. If you have a very straight-forward CRUD app, with Table-Class mappings, then an O/R mapper has a number of advantages in terms of simplicity and performance. However, if you have a complex/poor/large/etc. database model beyond your control, then an SQL mapper might be the only solution that works for you.
Generally an O/R mapper can create much more efficient mappings and cache strategies because it “knows” more about both the object model and the database. However, if it came down to a complex data transformation (say, flattening a relational parent/child tree), then an SQL mapper could likely do it much faster because it could take advantage of more efficient SQL. Generally you’ll have more control over the exact processing with an SQL Mapper, and therefore it offers more opportunity for tuning complex queries.
My suggestion: Try more than one. Do a couple of proofs of concept for your project and implement a deep “vertical slice” that you can test performance with. Every project will be different. For some, you’ll want Hibernate, others you’ll want iBATIS SQL Maps, others still you’ll want to use TopLink or maybe even raw JDBC.
For this reason, I think it’s more important and useful to learn how to evaluate and test these tools quickly and effectively; and it is less important to learn only one of them exclusively or even very well. Practice and get better at making good decisions, and worry less about finding “the grail”.
In the end the choice is yours and nobody can tell you what the right one is. Trust only yourself, draw your own conclusions and do lots of testing!
Clinton Begin
相关文章推荐
- Hibernate Oracle sequence的使用技巧
- jsp Hibernate批量更新和批量删除处理代码
- jsp hibernate的分页代码第1/3页
- 深入浅析mybatis oracle BLOB类型字段保存与读取
- MyBatis MapperProvider MessageFormat拼接批量SQL语句执行报错的原因分析及解决办法
- Struts2+Hibernate实现数据分页的方法
- Hibernate环境搭建与配置方法(Hello world配置文件版)
- JAVA+Hibernate 无限级分类
- SSH整合中 hibernate托管给Spring得到SessionFactory
- jsp hibernate 数据保存操作的原理
- hibernate中的增删改查实现代码
- 解决hibernate+mysql写入数据库乱码
- java优化hibernate性能的几点建议
- java Hibernate延迟加载
- hibernate 常用方法介绍
- SpringMVC整合mybatis实例代码
- 详解Java的Hibernate框架中的注解与缓存
- oracle+mybatis 使用动态Sql当插入字段不确定的情况下实现批量insert
- 浅析Java的Hibernate框架中的继承关系设计
- MyBatis学习笔记(二)之关联关系