ORM: Prelude to Greatness: the Requirements for Mapping

All of these solution approaches involve mapping between the application view and the database view. The problem with each of these approaches is that the mapping is defined within the application or the database. What we want is a solution that is outside of the application and outside of the database. We want the application to expose the meta-data about its structure and for the database to do the same thing. With modern languages and databases, this is a very easy thing to do. With all of this meta-data in place, we can create a mechanism to define and implement the mapping.

Here are some requirements for such a mapping mechanism:

First, it should be declarative in format. Creating and changing the definition of the mapping should not require programming skills or a deep knowledge of the database.

Second, it should be independent of the application implementation. For example, in the DotNet space, an ORM mechanism should work equally well for any language that works on the DotNet platform. As a part of this requirement, the domain model should have to contain minimal logic to invoke the mapping mechanism. I am going to address this issue in more detail later.

Third, it should be independent of the database management system. For example, the mapping should work equally well for any major database (with the option to add new database versions or vendors). Again, as part of this requirement, the database should be required to make minimal adjustments to work with the mapping mechanism.

Fourth, it should be able to optimize the interaction between the domain model and the database. In practical terms, because the database is inherently more costly, this optimization applies mostly to the database access. There are two sub points to consider here. A) The mapping mechanism must be able to create "very good" SQL to achieve what the declarative mapping has specified for the individual operations. I think that it also must be able to expose this SQL to the inspection of the DBA team to build their confidence that the optimization is competent. B) The mapping mechanism must be able to defer the execution of the individual operations and "batch" the operations to reduce the number of interactions across the network. This caching approach creates a secondary requirement to keep track of the identity of each object in the cache. If the domain model asks for a persistent object that is on the database and in the application cache, the domain model should get the object in the cache rather than a new copy from the database.

Fifth, it should support testing. Of specific concern here is that I want to be able to test the domain logic (including the logic that invokes the persistence mechanisms) without involving a database. The interaction with the database is a slow process (particularly when the initial setup and restore after any persisted changes is factored in). I want to be able to substitute a difference data store (such as an in-memory database) that avoids the long times associated with testing using a disk-based database.