01 persistence and domain modeling

Professional Open Source™

Persistence and Domain Modelling

© JBoss, Inc. 2003, 2004. 07/17/04 1

The persistence layer

 How does the Java application interact with the SQL database?
 Application layers
– group related code by concern
– prevent leakage of concerns
– have clear interfaces to avoid inter-layer dependencies

 A typical Layered Architecture and its interface dependencies:
Presentation Layer

Utility
and
Business Layer
Helper
Classes

Persistence Layer

© JBoss, Inc. 2003, 2004. 2

What is persistence?

 “Persistence”
– where data (state) outlives the process that created it

 In object-oriented applications:
– objects in a system are by default transient
– some of the objects in the graph are made persistent
– this subgraph of persistent instances can later be re-created in the same
process or another process

 We need a data model and data store for persistent data...

 The Relational Data Model and
 SQL-based Database Management Systems.

© JBoss, Inc. 2003, 2004. 3

PERSISTENCE APPROACHES

 1. A well-know and widely used DAO design pattern to wide complex
 JDBC code and no portable SQL from business logic.

 ORM also uses DAO pattern

© JBoss, Inc. 2003, 2004. 4


 2. EJB entity beans (CMP)
 Not fully object-oriented

 Doesn’t support polymorphic associations and queries

 Not portable across application servers

 Persistence runs only with EJB container

 In EJB3 no CMP, uses ORM for persistence
 Hibernate is good for JBOSS and major app. Servers
 Top Link is good for Oracle app. server

© JBoss, Inc. 2003, 2004. 5


 3. Object-oriented database system (ODBMS)
 JDO (Java Data Objects) are popular.
 But, object-databases are not widely adopted.

© JBoss, Inc. 2003, 2004. 6

PERSISTENCE APPROACH

4. THE BEST FOR THE MOST PROBLEMS
 ORM (Object-Relation Model)

 An API for performing basic CRUD operations on objects of persistent
classes
 A language or API for specifying queries that refer to classes and
properties of classes
 A facility for specifying mapping metadata
 A technique for the ORM implementation to interact with transactional
objects to perform dirty checking, lazy association fetching and other
optimization functions.

© JBoss, Inc. 2003, 2004. 7

PERSISTENCE APPROACH

THE BEST FOR THE MOST PROBLEMS
 ORM (Object-Relation Model)

 ORM advantages:

 Productivity - no tedious SQL code

 Maintainability - Fewer lines of code makes the system more
understandable

 Performance

 Vendor Independence

© JBoss, Inc. 2003, 2004. 8

Analyzing the business domain

 A software development effort begins with analysis of the problem domain

 At this stage, you, with the help of problem domain experts, identify the main
 entities that are relevant to the software system. Entities are usually notions
 understood by users of the system: payment, customer, order, item, bid, and so
 forth.

 All these entities are found in the conceptual view of the business, which we
sometimes call a business model.

 Developers and architects of object-oriented software analyze the business model and
create an object-oriented model, still at the conceptual level (no Java code). This
model may be as simple as a mental image existing only in the mind of the developer,
or it may be as elaborate as a UML class diagram

© JBoss, Inc. 2003, 2004. 9

What is Domain model ?

 Object Oriented model contains entities that you’re bound to find in
any typical system: category, item, and user. The entities and their
relationships (and perhaps their attributes) are all represented by this
model of the problem domain.

 We call this kind of object-oriented model of entities from the problem
domain, encompassing only those entities that are of interest to the
user, a domain model. It’s an abstract view of the real world.

 The domain model is a rich object model, with complex associations,
 interactions, and inheritance relationships

© JBoss, Inc. 2003, 2004. 10

Persistence classes of a domain model and their relationships

© JBoss, Inc. 2003, 2004. 11

Implementing the domain model

 An issue that any implementation will deal with is Separation of
concerns

 The domain model implementation is usually a central, organizing
 component; it’s reused heavily whenever you implement new
application functionality.

 So, u have to ensure that concerns other than business aspects
don’t leak into the domain model implementation.

© JBoss, Inc. 2003, 2004. 12

Addressing leakage of concerns

 The domain model implementation is such an important piece of code
that it shouldn’t depend on orthogonal Java APIs. For example, code
in the domain model shouldn’t perform JNDI lookups or call the
database via the JDBC API. This allows you to reuse the domain
model implementation virtually anywhere.

 Domain model should be concerned only with modeling the
 business domain. However, there are other concerns, such as
persistence, transaction management, and authorization. You
shouldn’t put code that addresses these crosscutting concerns in the
classes that implement the domain model. When these concerns start
to appear in the domain model classes, this is an example of
 leakage of concerns.

 Hibernate is a solution for just one of these concerns: persistence

© JBoss, Inc. 2003, 2004. 13

Transparent and automated persistence

 We use transparent to mean a complete separation of concerns
between the persistent classes of the domain model and the
persistence logic, where the persistent classes are unaware of—and
have no dependency on—the persistence mechanism
 The Item class, for example, doesn’t have any code-level
dependency on any Hibernate API. Furthermore:
– Hibernate doesn’t require that any special super classes or
interfaces be inherited or implemented by persistent classes.
– Persistent classes can be reused outside the context of
persistence, in unit tests or in the user interface (UI) tier, for
example.
– In a system with transparent persistence, objects aren’t aware of
the underlying data store; they need not even be aware that they
are being persisted or retrieved. Persistence concerns are
externalized to a generic persistence manager interface—in the
case of Hibernate, the Session and Query

© JBoss, Inc. 2003, 2004. 14

Domain Model and the paradigm mismatch

 Classes implement the business entities of our domain model
– attributes of the entity are properties of our Java class
– associations between entities are also implemented with properties

BillingDetails
User
accountNumber: String
userName: String 1 1..*
accountName: String
address: String
accountType: String
billingDetails: Set
user: User

Let’s see if there is a problem mapping this to tables and columns...

© JBoss, Inc. 2003, 2004. 15

Creating tables for the Domain Model

 SQL schema design for trivial cases is ... trivial:

create table USER (
USER_NAME varchar not null primary key,
ADDRESS varchar not null)

create table BILLING_DETAILS (
ACCOUNT_NUMBER varchar not null primary key,
ACCOUNT_NAME varchar not null,
ACCOUNT_TYPE varchar not null,
USER_NAME varchar foreign key references USER)

We’ll see the 5 problems of the O/R paradigm mismatch appear as we
gradually make our model more complex…

© JBoss, Inc. 2003, 2004. 16

The problem of granularity

Address
User
street: String
userName: String
city: String
billingDetails: Set
zipcode: String

– should we create a new ADDRESS table?
– should we create a new SQL data type and change the column?
– user-defined data types (UDT) are not portable and the standard is weak

 We usually add new columns to USER with built-in SQL data types:

create table USER (
USER_NAME varchar not null primary key,
ADDRESS_STREET varchar not null,
ADDRESS_CITY varchar not null,
ADDRESS_ZIPCODE varchar not null)

© JBoss, Inc. 2003, 2004. 17

The problem of subtypes

 We create subclasses of BillingDetails:

1 1..*
User BillingDetails

CreditCard Cheque

 and use polymorphism in Java to implement our billing strategy.

 How do we represent subtypes in our relational model?

© JBoss, Inc. 2003, 2004. 18

The problem of identity

 In Java, we have two notions of "sameness"
• object identity is the memory location of an object, a==b
• object equality (what is this really?), a.equals(b)

 In SQL databases, we identify a particular row using the primary key
and the table name. Often, this is a (meaningless) surrogate key!

What is the relationship between the three different types of identity in
our domain model? Is the surrogate key propagated into the domain
model?

© JBoss, Inc. 2003, 2004. 19

The problem of associations

 Object-oriented languages represent entity relationships as
object references (pointers) and collections of object references

 Relational databases represent entity relationships as
– copies of primary key values
– referential integrity ensured by foreign key constraints

 The mismatch:
– object references are directional, there is no such concept in the relational
model
– many-to-many associations require a link table in relational databases

© JBoss, Inc. 2003, 2004. 20

The problem of object graph navigation

 In Java, we "walk" the object graph by following references:
david.getBillingDetails().getAccountName()

 In SQL, we join tables to get the required data:
select * from USER u
left outer join BILLING_DETAILS bd
on bd.USER_ID = u.USER_ID
where u.USERNAME = “david"

Avoid the n+1 selects problem by minimizing the SQL
required for graph walking!

© JBoss, Inc. 2003, 2004. 21

The cost of the mismatch

 There problems can, at least theoretically, be solved using
handwritten SQL/JDBC
– by writing a lot of tedious code (maybe 30% of your codebase)
– The “mismatch problem” is real
– better UDT support in SQL will not solve all the issues
– not all applications are suitable for table-oriented approaches

Is the solution design patterns (DAO)
or programming models (EJB entity beans)?

"How should we implement the persistence layer in our application?"

© JBoss, Inc. 2003, 2004. 22

Object/Relational Mapping

 Object / Relational Mapping (ORM)
– solve the mismatch problem in middleware
– an ORM solution transforms data from the object-oriented representation
to the relational representation
– metadata governs this transformation

 Elements of an ORM implementation
– a programming model for the domain objects
– an API for performing CRUD operations
– a query language or other query facility
– a metadata facility

© JBoss, Inc. 2003, 2004. 23

Implementing POJO associations

 You use properties to express associations between POJO
 classes, and you use accessor methods to navigate from
 object to object at runtime.

 Let’s consider the associations defined by
 the Category class, as shown in the figure:
This is what the scaffolding code for the one-to-many self-
association of Category looks like:
public class Category {
private String name;
private Category parentCategory;
private Set childCategories = new HashSet();
public Category() { }
...
}
© JBoss, Inc. 2003, 2004. 24

Implementing POJO associations

 To allow bidirectional navigation of the association, you require two
attributes. The parentCategory field implements the single-valued end
of the association and is declared to be of type Category. The many-
valued end, implemented by the childCategories field, must be of
collection type. You choose a Set, because duplicates are disallowed,
and initialize the instance variable to a new instance of HashSet.

 Hibernate requires interfaces for collection-typed attributes, so you
must use java.util.Set or java.util.List rather than HashSet, for
example.
 The basic procedure for adding a child Category to a parent Category
looks like this:
– Category aParent = new Category();
– Category aChild = new Category();
– aChild.setParentCategory(aParent);
– aParent.getChildCategories().add(aChild);

© JBoss, Inc. 2003, 2004. 25

Implementing POJO Associations

 Whenever a link is created between a parent Category and a child
Category, two actions are required:
– The parentCategory of the child must be set, effectively breaking the association
between the child and its old parent (there can only be one parent for any child).
– The child must be added to the childCategories collection of the new parent
Category.
 It’s a good idea to add a convenience method to the Category class
that groups these operations, allowing reuse and helping ensure
correctness, and in the end guarantee data integrity:

© JBoss, Inc. 2003, 2004. 26

Adding logic to accessor methods

 For example, if your database stores the name of a user as a single
NAME column, but your User class has firstname and lastname
properties, you can add the following persistent name property to the
class:

© JBoss, Inc. 2003, 2004. 27

Performing validation in Accessor Method

 Accessor methods can also perform validation. For instance, in the
following example, the setFirstName() method verifies that the name
is capitalized:

© JBoss, Inc. 2003, 2004. 28

Dirty Checking issue

 Hibernate automatically detects object state changes in order to
synchronize the updated state with the database. It’s usually safe to
return a different object from the getter method than the object
passed by Hibernate to the setter. Hibernate compares the objects
by
 value—not by object identity—to determine whether the property’s
persistent state needs to be updated. For example, the following
getter method doesn’t result in unnecessary SQL UPDATEs:
– public String getFirstname() {
– return new String(firstname);
– }
 There is one important exception to this: Collections are compared
by identity!
 For a property mapped as a persistent collection, you should return
exactly the same collection instance from the getter method that
Hibernate passed to the setter method. If you don’t, Hibernate will
update the database, even if no update is necessary, every time the
state held in memory is synchronized with the database.
© JBoss, Inc. 2003, 2004. 29

01 persistence and domain modeling

More Related Content

What's hot (19)

Viewers also liked (6)

Similar to 01 persistence and domain modeling (20)

More from thirumuru2012 (14)

Recently uploaded (20)

01 persistence and domain modeling