Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: 21 Jun 2006 12:48:40 -0700
Robert Martin wrote:
> On 2006-06-13 09:32:58 -0400, "erk" <eric.kaun_at_gmail.com> said:
> > 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.
> True. However, our languages don't seem to be moving in that direction.
> Nor am I convinced that they should. While RM is a powerful technique
> for structuring data, I am not convinced that it is a powerful
> technique for structuring behavior.
No, it's not - it concerns constraints on behavior (preventing your database from becoming a free-for-all, or more generously just accumulating subtle data anomalies). Functional languages are far better for such things. I just think (after 8 years of O-O, beginning with being a true enthusiast) that coupling data and behavior hobbles both - although it's true that languages like Lisp and Smalltalk, that give you higher-level functional behavior, ameliorate that. For an example of what Java could have been (though it's not enough), look at Nice. I can't comment on C++, having never used it for anything functional.
> Render unto Ceasar. I have no problem with integrity rules being
> enforced by the database so long as they do not interfere with the
> testability of the application. However, any *application specific*
> constraints should be managed by the application instead of the
Agreed; I just don't think there are many of this breed. Most
> >> 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?
> No, I value the separation for it's own sake, not because of any
> particular tool.
OK, then our values simply differ. Separation has a cost, of course, and separating an application which manipulates data from the canonical definition of that data seems to me like a mistake, other than as a simple ADT implementation technique.