Home » Programming » Object Oriented Design for Database Centric Applications

Object Oriented Design for Database Centric Applications

April 27th, 2010 Leave a comment Go to comments

I’m writing a few fairly complex apps which are heavily data centric and I seem to be struggling to choose how to best implement such applications.  What I mean by data-centric is that data stored in the database is core to the application and most of the application has to do with working with the database, while the logic tends to be relatively simple.  So what’s the best way to do it…

I’ve been re-reading Martin Fowler’s Patterns of Enterprise Application Architecture in search for answers and the conclusion I’ve come to is that Object Oriented design isn’t particularly well suited for applications that heavily revolve around data stored in databases because of the mismatch between the patterns.  For example, it is very common to show data out of many tables in lists.  Working through a simple example for demonstration it should also be noted that this is only a simple example to demonstrate the issues faced, and in real life the logic is usually more complex… Taking a list of Customer Orders for example it’s pretty common to show the Customer Name in the list where the customer name is the fullFirst Name + ‘  ‘ + Last Name.  The Cstomer Full Name is also likely to be shown elsewhere (e.g. Invoices, Returns, etc).  So what are the options for implementing this in an OO fashion?

  1. Have the Order object reference the Customer object and then load both the Order and the Customer objects with a single query.  The pro of this approach is that the Customer object would contain the logic for creating the Full Name, but you don’t really want to load the entire customer object when you only want the Full Name and it doesn’t quite feel right to load only some of the data for the object either, as then the object isn’t really fully loaded.  So we’re kinda stuck between a rock and a hard place.
  2. Have the Order object implement the Customer Full Name field, but then it gets even more ugly, as you now also need to have the Customer First Name and Customer Last Name fields and you certainly don’t want to duplicate the Customer Full Name logic in the Order object as well as Invoice, etc, because that would be even worse, as there’s nothing worse than logic implemented in multiple places.   You could deal with the duplicate code issue by trying to factor the code out into some static method most likely, but that’s pretty ugly (e.g. having to call Customer.GetFullName in the Order object and passing across the parameters it needs to create it).

If you’re using procedural programming dealing with a situation like this would be pretty simple…  You retrieve the resultset and then you call a function that contains the logic for the Customer Full Name whenever you need that.  Pretty simple really.  In OO though, especially where your DAL returns a strongly typed object (e.g. Strongly Typed Dataset) you pretty much stuck.

If you have to choose between option 1 and 2 above, I’d have to say that Option 1 is better, as at least you don’t have to find creative ways to deal with duplicate logic issue, but it still doesn’t feel all that nice.

So what’s the answer to this?  How do you deal with this issue of mismatch between OO and database?  I don’t think there’s a perfect solution, as whichever way you look it’s ugly.  As bad as it sounds purely procedural programming/transaction script, seems to be the simplest to deal with these scenarios and seems to work the best as the code just feels natural and there’s no code duplication.  I guess one could just creates lots of static objects with static methods for this, but I don’t now if that’s such a great idea either.  Will need to think about it a bit more.

Share
Categories: Programming Tags:
  1. Sheffield
    May 12th, 2010 at 05:16 | #1

    After reading your comments this the O/R impedance may be the reason for the “no Sql” movement. It seems to be either you use a data store that easily maps to objects our you write your code that maps to the data. All this effort towards ORM seems futile and leads to a lot of complexity and constraints.

  2. May 12th, 2010 at 07:19 | #2

    Yes, that’s pretty much it… You either need to have something that’s more data-centric or object-centric… If you have complex logic it’s best to go object-centric if you have lots of data it’s best to go data-centric. As most of the stuff I do is heavily backed by databases I prefer to go data-centric for any stuff that’s stored in the database and object-centric for anything that’s mainly logic and may create the data for the data-centric stuff.

  1. No trackbacks yet.


8 − = three