Introduction
Currently,
Object-Relational mapping is probably the hottest topic of discussion
on the internet in terms of the various software development circles.
With all the hype surrounding ORM, it is easy to forget the why?. Why
does ORM exist? It would seem that ORM has become somewhat of a
religious war. One can only wonder if the ORM war will have people in
the future asking a why? The focus of Object-Relational mapping is to
solve the object-relational impedance mismatch. I.e. the object model
does not equal the relational model and this is considered by many to
be a problem. There are those that have subscribed to the viability of
ORM as a persistence strategy, and there are those that have not. Some
have questioned whether the object-relational impedance mismatch is a
problem at all. Others argue that the object-relational impedance
mismatch issue is being solved on the wrong side of the equation. I.e.
there are those that advocate the use of Object-Oriented databases as a
solution and not ORM. The fact that ORM has created so much attention
and heated debate implies that there is something of importance or at
least perceived importance. I leave it up to you to decide. That
something deserves a closer inspection to separate the hype from the
fact. The aim of this article is to encompass important a view for and
against ORM. By so doing, it is intended to establish a different, or
at least more informed, perception of ORM regardless of what the
current perception may be.
Intent
To
be fair, the topic of Object-Relational Mapping requires a book to
address all the matters relating to it in its entirety. I provide just
enough information in this article to allow one to consider ORM from a
pragmatic perspective.
Object-Relational
Mapping as a persistence strategy is both a statement and a question.
In the first instance, I am implying that ORM is a persistence
strategy. In other words, ORM is a viable technology in terms of
satisfying ones persistence requirements. In the second instance, I am
questioning ORM as a persistence strategy. I.e. Is ORM a viable
solution in terms of satisfying ones persistence requirements. The
focus of this article is not on the best ORM tools that are available. Best is at best transient and what is best today may not be whats
best tomorrow. Instead, the focus is on ORM at a conceptual level. The
reason that I have chosen to focus my attention at a conceptual level
is due to the nature of change. ORM tools will appear, change,
disappear and reappear. Technology will evolve and so will ORM tools. I
consider the concepts behind ORM to be of far more significance and
value. This allows one to view ORM in a pragmatic and hopefully
unbiased view. Therefore, the intent of this article is to view ORM at
a conceptual level, in an unbiased manner, and assume a technology
agnostic approach.
For the purpose of clarity, the intent of this article is further summarized to be as follows:
- Description of ORM
- What is ORM?
- Why does it exist?
- In what form does it exist?
- What are the problems associated with ORM?
- Viability of ORM as a persistence strategy
- Discussion on the requirements of a persistence strategy. Determining how well if at all ORM satisfies persistence requirements.
- Reusability
- Maturity
- Time and Cost
- Architecture
- Choosing an ORM
- Commercial vs. Open Source vs. In-house
Failing with ORM
Object-Relational Mapping
Often,
a good way of understanding what something does, is to understand the
reason for its existence. I.e. why does it exist? In terms of
enterprise software development, most if not all software systems deal
with getting data in and out of a data store. In this context the form
of data store is unimportant. What is important is how one deals with
the data store persistence. Data persistence implies the concept of
persisting and retrieving data. It is a common and recurring
development challenge. For those that are familiar with design
patterns, the aforementioned statement should sound oddly familiar.
Design patterns, at their simplest definition, are tried and tested
solutions to common and recurring challenges. Therefore, is there or
are there design patterns to deal with data persistence. Yes, there are
many patterns that one might employ to deal with the data persistence
challenge. Is ORM such a design pattern? ORM may use many design
patterns to achieve its end. Whether it in and of itself is a pattern
is probably a discussion best left to another article or forum. ORM is
a technique that one might choose as a data persistence strategy. ORM
is a solution, not the solution. It does help address a common
development challenge, that being of data persistence. The popular term
to describe the data persistence issue is that of the object-relational
impedance mismatch. The question that arises is whether the impedance
mismatch is really an issue. The Java development community seems to
have adopted ORM well before any of the other development communities.
I used the word seem as I have not encountered all development
communities and therefore cannot say with certainty that this is the
case. The Microsoft development community has chosen to ignore the
object-relational mismatch until recently. I say recently because there
only seems to be a boom in terms of the availability of ORM tools in
recent times. I am not, however, implying that Microsoft has chosen to
ignore the mismatch issue. Before continuing the discussion of ORM, the
following points are highlighted in terms of understanding the
definition of ORM.
- It
provides a way to resolve the object-relational impedance mismatch.
This object-relational impedance mismatch is considered to be the core
problem.
- It is a technique for converting data between a relational database and an object-oriented programming language
- It is an abstraction of data persistence code
- The result of an ORM implementation is often likened to that of a virtual object database.
- ORM provides us with database independence
To further elaborate on what ORM is, I discuss ORM in terms of the following challenges:
- Core Challenge
- Conceptual Challenge
- Legacy Challenge
- Usability Challenge