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

Robert Martin wrote:
> On 2006-06-02 08:28:55 -0400, "Tony Andrews" <andrewst_at_onetel.com> said:
>
> >>
> >> 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.
>
> Create Customer (and all the other CRUD and etc functions) would be
> split between the two layers. Application management happens in the
> higher layer. Data access and management happens in the lower layer.

Well, this is what you said that started this whole discussion:

>No, a DBMS is a bucket of bits with some low level rules to manage
>those bits. An OO application provides the beavior that the customer
>wants to see. We can completely eliminate the DBMS and replace it with
>another of an entirely different form (non Relational for example) and
>still have all the business behavior we need.
>The people who sell databases have sold you, and the industry, a
>misconception: that the database is the heart of the system. This is
>flawed. The heart of the system is the application code. The database
>is a detail to be decided at the last possible moment and kept in a
>position so flexible that it can be swapped out for another at a whim.

So it seems to me that your "split between the two layers" means that all the complex logic is done in the application layer, and merely the "CRUD" is passed down to the DBMS layer - like I said: "insert [row] into [table]" type commands. So all the data manipulation power of a DBMS (dealing with *sets* of data) is ignored and the DBMS only handles single-row selects, inserts, updates and deletes ("CRUD").

Of course, if you used the DBMS properly then there wouldn't be so much application to write, and where's the fun and bucks in that? Received on Fri Jun 23 2006 - 11:02:47 CEST