1 / 17

ORM Object-Relational Mapping

ORM Object-Relational Mapping. Object Persistence. Persistence is the ability of an object to survive the lifecycle of the process, in which it resides. it is a desired feature in most nontrivial applications. Persistence implies that data lives longer than objects .

kimberlypjones
Download Presentation

ORM Object-Relational Mapping

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ORMObject-Relational Mapping

  2. Object Persistence • Persistence is the ability of an object to survive the lifecycle of the process, in which it resides. • it is a desired feature in most nontrivial applications. • Persistence implies that data lives longer than objects. • When the program is stopped/restarted, the data from last execution is readily available.

  3. Persistence Options • Storing information in simple data files: • Insufficient for all but the most trivial cases (e.g., configuration data). • Using object Serialization: • Supported in Java “out of the box”. • Perfect match for Java objects. • No support for non-Java environments. • Monolithic (save/store all objects every time). • Completely unusable for real-world cases.

  4. Persistence Options (cont.) • Using an Object-Oriented Database (OODBMS). • Maps nicely to object-oriented programs. • Not very popular. • Performance problems. • No industry standard.

  5. Using a Relational Database • The most common solution: a relational database. • Information is stored in tables. • Access via SQL. • Based on industry standards. • Widely accepted. • Unrivaled performance. • But… How?

  6. Using a Relational Database (cont.) • The basic idea: • Map every persistent class to a database table • e.g., Client ↔ CLIENT • Map every class field to a table field. • e.g., String Name ↔ NAME (VARCHAR) • Every class instance represents a database row. • Access the database using SQL. • In the case of Java, use JDBC or libraries that rely on it.

  7. The Paradigm Mismatch • However, there are many inherent problems to mapping object-oriented data to databases. • Granularity. • Subtypes and polymorphism. • Identity. • Associations. • Collections. • … and other problems. • Let’s review a few of these problems in detail.

  8. The GranularityProblem • Consider the following (very typical) database table:

  9. The GranularityProblem (cont.) • Does the following class match? classClient { String name; String mailAddressStreet; String mailAddressCity; String mailAddressState; String mailAddressZip; String billingAddressStreet; String billingAddressCity; String billingAddressState; String billingAddressZip; ... methods }

  10. The GranularityProblem (cont.) • What we want is the following two classes: • OOP and databases work on different levels of granularity. class Client { String name; Address mailAddress; Address billingAddress; ... methods } class Address { String street; String city; String state; String zip; }

  11. Subtyping and Polymorphism Problem • Consider the following class diagram:

  12. Subtyping and Polymorphism Problem (cont.) • How do we store BillingDetails in the database? • How do we represent the relationship between Client and BillingDetails? • A foreign key can only point to one other table – CreditCard or BankAccount.

  13. Identity Problem • A single database row is always unique. • Assuming a primary key is used. • But in OOP, multiple objects in memory can represent the same notion. • Two objects that map to the same database row. • Database identity is different from object identity (“==”) and object equality (“equals()”).

  14. Coping with the Paradigm Mismatch • The paradigm mismatch greatly complicates OOP/RDBMS interoperability. • Up to 30% of enterprise Java application code deals with persistence. • Tedious SQL/JDBC. • Bridging information representation. • Caused more than one project to sink.

  15. Coping with the Paradigm Mismatch (cont.) • The most accepted solution today: using middleware. • A library that bridges OOP to RDBMS. • “Object/Relational Mapping” (ORM). • Java middleware solutions for persistence: • J2EE Entity EJBs. • Hibernate. • JDO (Java Data Objects).

  16. Characteristics of a good ORM Solution • Transparent (non-intrusive). • Efficient (enables lazy-loading, selective updates, caching, etc.). • Powerful (advanced querying capabilities, a lot of configuration options). • Flexible (can fit into various environments such as Servlet Containers, EJB Containers, Plain Java Apps, etc.). • Easy to use (mild learning curve, good testability, etc.). • Supports OO idioms and concepts (inheritance, polymorphism, etc.). • Standard.

  17. ORM Options • EJB 3 • Hibernate • JDO • TopLink • CocoBase • Castor • …

More Related