Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: <frebe73_at_gmail.com>
Date: 13 Jun 2006 09:12:03 -0700
Message-ID: <1150215123.463187.38320_at_h76g2000cwa.googlegroups.com>


> > The big questing is: Why do you want to unplug the SQL DBMS?
>
> I don't want to replace the DB, I just want it to be replaceable. This
> just makes for good modularity, and good testability.

Making something replaceable without actually using that feature doesn't make much sense. Is modularity and testablility the two only reasons why you want to make the SQL DBMS replaceble?

Does modularity has a value itself? I thought modularity was a tool to archieve an objective?

In what way does the application become easier to test doing the SQL DBMS replaceble? Don't you want to test the SQL statements? Don't you have to write a large amount of code to do the same stuff as the SQL statements? Won't you introduce a lot of bug writing this code, that don't exists in the real application? Why don't you use a light-weight all-in-RAM database (like HypersonicSQL) for your tests? If I can live with a slow test execution (during night-time), do I still have to do the SQL DBMS replaceble?

> I do not want to
> sacrifice any of the power of the DB,

What kind of result will your "persistence" layer return to the "business" layer? Collections of domain objects? What if I want to make a query that do not return domain objects (select count(*) from customer)? What if the select statement joins tables that belongs to different domain objects?

Fredrik Bertilsson
http://moonbird.sourceforge.net Received on Tue Jun 13 2006 - 18:12:03 CEST

Original text of this message