Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Fri, 2 Jun 2006 00:55:14 -0500
Message-ID: <2006060200551425485-unclebob_at_objectmentorcom>
On 2006-05-31 09:14:33 -0500, "Tony Andrews" <andrewst_at_onetel.com> said:
>> I was doing neither. I was expounding an attitude about DBMSs that I
>> have found useful over the years. When I put a system together I treat
>> the DBMS as a detail. I isolate it from the application code as much
>> as possible. What results is an application design which is deeply
>> partitioned into areas that know a lot about the DB and areas that know
>> nothing about the DB. This is just good decoupling.
>
> Decoupling is good, if done at an appropriate level. However, given
> your preference for swapping out DBMSs "at a whim" you clearly have no
> choice but to use the lowest common denominator abilities of all DBMSs
> that might be chosen, which probably amounts to some very simple
> low-level DML and SELECT statements. Then you effectively build your
> own pseudo-DBMS on top of this with application code. What a waste of
> time and effort, not to mention the money you spent buying a DBMS of
> which you refuse to use 95% of the power!
Finally an argument with some subtance in it! Thank you!
Yes, it would be a shame if we were unable to utilize the power of the tool. So, what if we put the decoupling level a bit higher than the schema. What if the application defines a set of data management services that are implemented by another layer? What if that layer can make use of all the nifty features of the DBMS? What if that layer could also be replaced with a completely different mechanism?
-- Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 |Received on Fri Jun 02 2006 - 07:55:14 CEST