Transcript ORM - Webcourse

ORM
Object-Relational
Mapping
1
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.
2
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.
3
Persistence Options (cont.)
Using an Object-Oriented Database (OODBMS).
Maps nicely to object-oriented programs.
Not very popular.
Performance problems.
No industry standard.
4
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?
5
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.
6
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.
7
The Granularity Problem
• Consider the following (very typical) database table:
CLIENT
NAME
MAIL_ADDR_STREET
MAIL_ADDR_CITY
MAIL_ADDR_STATE
MAIL_ADDR_ZIP
BILLING_ADDR_STREET
BILLING_ADDR_STATE
BILLING_ADDR_STATE
BILLING_ADDR_ZIP
8
The Granularity Problem (cont.)
• Does the following class match?
class Client {
String name;
String mailAddressStreet;
String mailAddressCity;
String mailAddressState;
String mailAddressZip;
String billingAddressStreet;
String billingAddressCity;
String billingAddressState;
String billingAddressZip;
... methods
}
9
The Granularity Problem (cont.)
• What we want is the following two classes:
class Client {
String name;
Address mailAddress;
Address billingAddress;
... methods
}
class Address {
String street;
String city;
String state;
String zip;
}
OOP and databases work on different levels of granularity.
10
Subtyping and Polymorphism Problem
• Consider the following class diagram:
Client
-name
-address
BillingDetails
-billingDate
CreditCard
BankAccount
-cardType
-cardNumber
-expirationDate
-bankName
-aaccountNumber
11
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.
12
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()”).
13
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.
14
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).
15
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.
16
ORM Options
• EJB 3
• Hibernate
• JDO
• TopLink
• CocoBase
• Castor
…
17