Spencer: May 2008 Archives

So this will probably be a first in a series of posts related to software design patterns and all my inner strugglings regarding what is hype and what is real.  There are probably lot of other people out there that may have similar strugglings, and more than likely there are some out there that are blissfully unaware of the concerns.  So what am I talking about?  Well let's start where I started a while ago, with ORMs.

ORMs (Object Relational Mappers) are a basically a way to have a OO layer between your application code and your RMDBS.  There are some basic "features" of an ORM, but not all ORMs support all of these.  In any case here is a list of common features:

1. OO interface to tables, rows, functions, etc, in your database.  So you can use native application code and OOP to interact with your data.
2. A more elegant/simpler API to interact with your database.  Many ORMs use some other database API under the hood, but add routines and interfaces (or simplifies calls) that the normal API lacks.
3. Object (data object) persistence.  So that you can create an instance of some data you are modeling and then be able to store that object and revive it later with state preserved.
4. Abstract the interaction between your application code and your database such that in the future if/when you need to move to a different database you application code will require as little change as possible.  Ultimately, changing databases should be a matter of configuration files, or perhaps even less work.  And your app code wouldn't even know the difference between Postgres, MySQL, SQLite, or something else.