Software design patterns and excess

| | Comments (0) | TrackBacks (0)
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.

All those things sound great don't they?  So what is the concern?  What is the inner struggle?  Well, I think it boils down to a couple of things:

  1. ORMs are slow.  For all their nifty-hood, ORMs add more abstraction, more layers of code, and therefore more overhead with interactions with your data.  For performance critical apps, ORMs are yet another thing to be concerned about.  How many times do application designers have to chose between portability and performance?  This comes up often.
  2. Do they really make your app code better?  Or more portable?  Or easier to maintain?  Or is there a lot of work just to get an ORM configured just for the theoretical chance you app will run on a different database?  If you spent some time making standard SQL that should work across databases, isn't that 95% of the job already?
  3. Is forcing your database into app code objects a good thing in the first place?
  4. Is there an design weakness with too much OOP?  When your code crosses a threshold of complexity due to so much abstraction that no one is really able to know what does what and what the execution code path really looks like, is there a problem with obfuscation by code bloat?  This one doesn't so much speak to ORMs directly, but in the general direction of software design that ORMs can point to.
  5. ORMs are in style at the moment, but in reality many of their features have been in use in some other form for quite some time.  Is there really much benefit in going "all the way" with them?

So, as you can see I have more questions than answers here.  Not really having a lot of experience using any ORM, I may be just simply a noob and not really get it yet.  But there are other factors going on in my life that support concern number 4 above in regard to other aspects of software design.  And so I don't think that my concerns with ORMs are simply noob-ish.

I'll post again with more another time.

0 TrackBacks

Listed below are links to blogs that reference this entry: Software design patterns and excess.

TrackBack URL for this entry: http://spencerchristensen.com/mt/mt-tb.cgi/9

Leave a comment

About this Entry

This page contains a single entry by Spencer published on May 4, 2008 10:05 AM.

Where's your cube again? was the previous entry in this blog.

Sleep and the art of staying awake is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.01