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

Robert Martin wrote:
> 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?

What sort of things would this layer do? In my world it would perform business logic, with procedures for actions such as "create employee", "calculate payroll". However I suspect in yours these would be DBMS-agnostic OO methods, and this layer would be doing something lower level - though I can't quite imagine what other than generic "insert [row] into [table]" type commands. Received on Fri Jun 02 2006 - 14:28:55 CEST