[Dolenc] Hibernate vs. iBatis

3,816 views
3,659 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,816
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
137
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

[Dolenc] Hibernate vs. iBatis

  1. 1. HIBERNATE VS. IBATIS OR TWO WAYS OF DATABASE ACCESS BOŠTJAN DOLENC, MARAND INŽENIRING
  2. 2. WHAT WE'RE ABOUT TO SEE: • A bit about relevancy • The ORM way (with Hibernate examples) • The JDBC+ way (with iBatis examples) • Problems • Crossing the chasm • Discussion (time permitting)
  3. 3. RELEVANCY • Data matters more than code • JDBC sucks – Aimde at system development – Lacks higher level features: statement manipulation, encapsulation, caching – Cumbersome use • Objects ≠ Relations (holy war)
  4. 4. ORM WAY • Object/class centric approach • Strict Object-Relational Mapping or “I hate bloody SQL” • Using Hibernate 3.x (and JDK <1.5)
  5. 5. ORM EXAMPLE
  6. 6. ORM EXAMPLE - CONTINUED
  7. 7. JDBC+ WAY • SQL centric approach • Improved JDBC or “Ad-hoc queries without JDBC horrors”
  8. 8. JDBC+ EXAMPLE
  9. 9. JDBC+ EXAMPLE - CONTINUED
  10. 10. ORM PROBLEM: 1+N FETCHING 1 2 10 1 11 1 42 10 12 1 43 11 13 2 44 11 22 42 45 12 23 42 46 13 ... ...
  11. 11. ORM PROBLEM: 1+N FETCHING - CONTINUED • Eager loading to the rescue: – Next-level-only fails in deep hierarchies – All-levels fails when accessing only top-level • HQL to the rescue: – from Customer c join c.contracts co join co.bundles b join b.services s
  12. 12. ORM PROBLEM: MASSIVE UPDATES for (ServiceTimeline st : services) { if (st.getValidTo() == null) 1 1.1. { st.setValidTo(newDate); 2 1.2. 1.12. } 3 15.10. } 4 1.2. 5 1.1 1.12. update service_timeline set valid_to = #newDate# where valid_to is null
  13. 13. OTHER ORM PROBLEMS: • xQL (HQL, JP QL) ≠ SQL – Tools – Limited to programmers • POJOs sometimes aren’t Plain and Old – Common base class, proxies, code generation, annotations... – Build/startup overhead, subtle reflection bugs
  14. 14. JDBC+ PROBLEM: LOTS OF WORK FOR SIMPLE THINGS
  15. 15. JDBC+ PROBLEM: LOTS OF WORK FOR SIMPLE THINGS - CONTINUED
  16. 16. JDBC+ PROBLEM: MANUAL SAVING (INSERT/UPDATE) IS TEDIOUS 1 1 2 10 1 2 11 1 3 42 10 12 1 43 11 4 13 2 44 11 5 22 42 45 12 23 42 46 13 ... ...
  17. 17. OTHER JDBC+ PROBLEMS: • Limited caching – Caches only query results (by definition) – ORM can “understand” mutations, JDBC+ can’t • Fear of SQL – People problem – Training and tools help a lot
  18. 18. MIX APPROACHES TO CROSS THE CHASM: From ORM toward JDBC+ From JDBC+ toward ORM • Eager flushing • Save phase at the end • HQL, SQL queries • Get-by-id, update, insert, delete for each class • Form-based / non-generic • Active Record-like DAOs, development reflection + dynamic SQL • Discipline, examine the • Custom development inner workings
  19. 19. CONCLUSION • The ORM-SQL chasm might be scary • It’s not that wide • You can stay in the middle with some tricks

×