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

Robert Martin wrote:
> Functionality can be split between many modules. Given a particular
> functionality, part of it will be SQL related, and part of it will not.

The word "functionality" is troubling. Presumably the underlying domain objects are the core of the application, and therefore not something that can be hidden away from other modules - those modules mostly depend on the domain objects, right? And if those are state-bearing objects (if not they're not really objects), then they're data structures. Just very feeble ones.

> We would like those two parts to be separated at the source code
> level, with the dependencies pointing AWAY from the SQL modules. This
> allows us to change out the data management technology (if not the
> theory),

I think I agree with you here, but would like some more explanation. What do you mean by "if not the theory"? The different "storage technologies" have very different data models - do you advocate sticking to one of them for a given application, or a given business domain?

> and also test the application code without running the DB.

If the language itself included the ability to define relations and constraints (and obviously keep those in sync with the DBMS), this would be equally easy.

> > I don't challenge your goal, but relational model abstractions are too
> > sophisticated to give up to such primitive methods.
>
> Nobody is talking about giving anything up. The position of a line of
> code does not limit it's power. The fact that we want the SQL in
> source modules that are independent, does not mean that they can't be
> used all through the application.

So you're still talking about "mapping" SQL to objects, which won't have (or will have re-implementations of) the constraints and types in the database?

> > Striving to make
> > your application database agnostic results in the flaws which expose
> > designers data management ignorance.
>
> I disagree. Striving to separate your application into database
> dependent and database independent partitions enhances flexibility and
> testability, without reducing power.

Would having easier-to-use DBMSs, even in-memory ones, do the same for you? I agree with enhancing testability, though I'm not sure what you mean here by flexibility - in "storage technology"? By that, do you mean just switching from Oracle to Postgres or vice versa, for example?

• Eric