Object persistence means that individual objects can outlive the application process;
they can be saved to a data store and be re-created at a later point in time. The
object/relational mismatch comes into play when the data store is an SQL-based
relational database management system. For instance, a network of objects can’t be
saved to a database table; it must be disassembled and persisted to columns of portable SQL datatypes. A good solution for this problem is object/relational mapping
(ORM), which is especially helpful if we consider richly typed Java domain models.
A domain model represents the business entities used in a Java application. In
a layered system architecture, the domain model is used to execute business logic
in the business layer (in Java, not in the database). This business layer communicates
with the persistence layer beneath in order to load and store the persistent
objects of the domain model. ORM is the middleware in the persistence layer that
manages the persistence.
ORM isn’t a silver bullet for all persistence tasks; its job is to relieve the developer
of 95 percent of object persistence work, such as writing complex SQL statements
with many table joins, and copying values from JDBC result sets to objects or
graphs of objects. A full-featured ORM middleware solution may provide database
portability, certain optimization techniques like caching, and other viable functions
that aren’t easy to hand-code in a limited time with SQL and JDBC.
It’s likely that a better solution than ORM will exist some day. We (and many
others) may have to rethink everything we know about SQL, persistence API standards, and application integration. The evolution of today’s systems into true relational database systems with seamless object-oriented integration remains pure
speculation. But we can’t wait, and there is no sign that any of these issues will
improve soon (a multibillion dollar industry isn’t very agile). ORM is the best solution
currently available, and it’s a timesaver for developers facing the object/relational
mismatch every day. With EJB 3.0, a specification for full object/relational
mapping software that is accepted in the Java industry is finally available.
they can be saved to a data store and be re-created at a later point in time. The
object/relational mismatch comes into play when the data store is an SQL-based
relational database management system. For instance, a network of objects can’t be
saved to a database table; it must be disassembled and persisted to columns of portable SQL datatypes. A good solution for this problem is object/relational mapping
(ORM), which is especially helpful if we consider richly typed Java domain models.
A domain model represents the business entities used in a Java application. In
a layered system architecture, the domain model is used to execute business logic
in the business layer (in Java, not in the database). This business layer communicates
with the persistence layer beneath in order to load and store the persistent
objects of the domain model. ORM is the middleware in the persistence layer that
manages the persistence.
ORM isn’t a silver bullet for all persistence tasks; its job is to relieve the developer
of 95 percent of object persistence work, such as writing complex SQL statements
with many table joins, and copying values from JDBC result sets to objects or
graphs of objects. A full-featured ORM middleware solution may provide database
portability, certain optimization techniques like caching, and other viable functions
that aren’t easy to hand-code in a limited time with SQL and JDBC.
It’s likely that a better solution than ORM will exist some day. We (and many
others) may have to rethink everything we know about SQL, persistence API standards, and application integration. The evolution of today’s systems into true relational database systems with seamless object-oriented integration remains pure
speculation. But we can’t wait, and there is no sign that any of these issues will
improve soon (a multibillion dollar industry isn’t very agile). ORM is the best solution
currently available, and it’s a timesaver for developers facing the object/relational
mismatch every day. With EJB 3.0, a specification for full object/relational
mapping software that is accepted in the Java industry is finally available.