HIBERNATE VS IBATIS- -
CLITON BEGIN's words:
"The biggest difference between Hibernate and the iBATIS DB Layer,or mor 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 straght-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!
'
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 straght-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!
'
- 作者： lastsky 2004年04月27日, 星期二 17:37
Trackback
你可以使用这个链接引用该篇日志 http://publishblog.blogdriver.com/blog/tb.b?diaryID=132205
回复
- 评论人：shzxrcxs
Thu May 17 05:41:23 CST 2007
pixwxwmewh[url=http://zvore.yi.org/82177478.html]brazilian pussy[/url][url=http://xenggi.66ghz.com/46330167.html]gun games[/url][url=http://wxaxw.22web.net/34298878.html]tatoo designs[/url][url=http://www32.websamba.com/viora/94041272.html]model com[/url][url=http://uenvc.22web.net/16709694.html]football games[/url][url=http://ninfrb.yi.org/20352297.html]blades glory cam xvid mvs[/url]
- 评论人：tqzrcuzc
Thu May 17 04:00:10 CST 2007
abxwxwmefr[url=http://zvore.yi.org/82177478.html]brazilian pussy[/url][url=http://xenggi.66ghz.com/46330167.html]gun games[/url][url=http://wxaxw.22web.net/34298878.html]tatoo designs[/url][url=http://www32.websamba.com/viora/94041272.html]model com[/url][url=http://uenvc.22web.net/16709694.html]football games[/url][url=http://ninfrb.yi.org/20352297.html]blades glory cam xvid mvs[/url]
