Persistence Strategies: DAO (Data Access Objects) and ORM (Object-Relational Mapping) – Part 1

Article 1: Overview

I’ve been working on some recent projects, both personal and professional, where the topic of object persistence has come up. As I’ve learned over the last few months, while this is certainaly a common problem and there are no shortage of solutions out there, this can be a challenging area. While researching different solutions, I’ve focused both on generic design patterns and best practices, as well as language/platform specific implementations. My area of interest has really focused on solutions for both Perl and Java. However, there are far more (and more mature) options out there for Java at the moment.

Generically speaking, data/object persistence essentially boils down to one of two categories:

• You need a way to persist, or store, your business objects for retrieval at a later time. Top->Down: Applies to new projects where you aren’t constrained by a legacy schema.

• You need a way to take an existing database schema, and provide a high-level OO domain model (business objects). Bottom->Up: Existing projects where you must map between your database tables and your business objects. Typically a 1:1 mapping between your table and class.

As with most people, my perstistence requirements fall into category 2. One of the challenges is in the scenario where there are many tables and there is a hierarchical relationship between objects. As a very generic example, lets say you have 4 objects.

Objects A, B, C, D

Where A can have 1 or more B, B can have 1 or more C, and C can have one or more D. While this 1 to many (m:n) relationship may not be that uncommon, the challenge is database load and performance. If you instantiate object A, you more than likely would not want a cascaded load where all objects are loaded. This is particualy true if your collections have tens of thousands of rows. This is where the decision to use best patterns and practices to roll your own solution, and choosing an existing perstistence framework becomes much easier. Solutions such as IBatis and Hibernate support lazy loading and caching, which address these issues.

Before I get into the topic of perstistence frameworks, I’ve done some investigation on DAO (Data Access Objects) and will publish this next. While DAO is not a full fledged perstistence solution, it does provide a clean way to seperate your business objects from your data retrieval mechanism (i.e. Removes SQL from your code). Over the next few weeks I plan on posting my findings as I make progress. My hope is that some of my findings may be helpful to people who have just started research similar to this.