01 persistence and domain modeling

Professional Open Source™

© JBoss, Inc. 2003, 2004. 1

07/17/04

Persistence and Domain Modelling

© JBoss, Inc. 2003, 2004. 2


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:

Persistence Layer

Business Layer

Presentation Layer

Utilityand

HelperClasses

© JBoss, Inc. 2003, 2004. 3


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. 4


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. 5



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. 6



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

© JBoss, Inc. 2003, 2004. 7


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. 8


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. 9


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. 10


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. 11


Persistence classes of a domain model and their relationships

© JBoss, Inc. 2003, 2004. 12


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. 13


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. 14


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. 15


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

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

Domain Model and the paradigm mismatch

UseruserName: Stringaddress: StringbillingDetails: Set

BillingDetailsaccountNumber: StringaccountName: StringaccountType: Stringuser: User

1 1..*

© JBoss, Inc. 2003, 2004. 16


Creating tables for the Domain Model

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

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

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)

© JBoss, Inc. 2003, 2004. 17


The problem of granularity

– 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)

UseruserName: StringbillingDetails: Set

Addressstreet: Stringcity: Stringzipcode: String

© JBoss, Inc. 2003, 2004. 18


The problem of subtypes

We create subclasses of BillingDetails:

and use polymorphism in Java to implement our billing strategy.

How do we represent subtypes in our relational model?

User BillingDetails1 1..*

CreditCard Cheque

© JBoss, Inc. 2003, 2004. 19


The problem of identity

In Java, we have two notions of "sameness"A. object identity is the memory location of an object, a==b

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. 20


The problem of associations

Object-oriented languages represent entity relationships asobject 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. 21


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. 22


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. 23


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. 24


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. 25


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. 26


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. 27


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. 28


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. 29


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.

01 persistence and domain modeling

Technology

Transcript of 01 persistence and domain modeling