Re: Clean Object Class Design -- What is it?

Chris,

You've outlined the alternatives beautifully, with this:

> 1. Run a relational database and have multiple applications access it.
>
> 2. Run some kind of database (doesn't really matter what kind, so long as
> you can manage to store objects in it somehow), and write an object
 oriented
> class library to control access to it.

To answer your question of how I value these alternatives, my mind is in transition about this right now.
There is a lot that's relevant to this value judgement, and a lot of it is stuff I don't know. Basically, the industry is progressing (or thrashing depending on your point of view) faster than I can learn.

If there were an orderly, rational, and civilized discussion between practitioners who favor one alternative over the other, but are familiar enough with both alternatives so that the discussion doesn't degenerate into meaningless arguments about terminology, then I would want to learn as much as I could from that discussion, and contribute where I can, which might not be very much. The discussion in this forum is not that useful to me, because of ad hominem attacks, product promotional ax grinding, and mischaracterizations of both the OO paradigm and the Relational paradigm (if I can call it that).

Having avoided your question, ;), let me tell you what I think is a BAD compromise between the two alternatives:

Design an application entirely around an OO data model. Defer all of the management reporting functions of the application until version 3 or 4 in the name of "time to market". Store all the persistent objects in an RDBMS, for the sake of robustness about issues like ACID, etc. Use the JDBC or the like, as an interface between the engines that understand the objects and the server that is responsible for persistence. Reduce the Data dictionary in the RDBMS to gibberish, because that's not where the real model lies, anyway.

Then, as the application gets deployed, use the SQL interface, and some lowly report writer like Crystal Reports to fill in the gap in management reporting created by the decision to leave that piece of functionality to version 3 or 4. Have the report developers go nuts trying to concoct, by reverse engineering, a relational schema that maps the result of an OO design, with not documentation. Consequently, have a simple function like management reporting fail, because the mismanagement of data definitions has made a simple function damn near impossible.

For lack of relevant and timely information, allow management to fail. For lack of adequate management, allow the business to move from vigorous growth to sudden liquidation. Throw everybody out of work. And then repeat the cycle.

Has anybody out there seen a scenario like the one I've outlined? The fundamental problem with the scenario is settling for a BAD COMPROMISE. The bad compromise can be summarized thus: "Store a bunch of objects in tables. Then pretend they are a bunch of relations." Of course, what I've outlined isn't theory. It's what happens when practice gets too far ahead of theory.

All of this still doesn't address your question, Chris, which is a very good one. I honestly don't know where I think the industry ought to go. I could make a guess, but it would just be idle speculation. Maybe I'll speculate in a future post.

--
Regards,
    David Cressey
    www.dcressey.com
"Chris Smith" <cdsmith_at_twu.net> wrote in message
news:9i4tku$7v2$0_at_dosa.alt.net...


> "David Cressey" <david_at_dcressey.com> wrote ...

> > I'm not sure exactly what you mean by "embedding our database into

> > applications".  The only way I can interpret it is to mean PRECISELY

 what


> > the inventors of database systems in the 1970s were trying to get away

 from:


> > the idea that all the data definitions were buried somewhere in source

 code,


> > and the only way to manage data definitions was to get involved in the

> > details of source code maintenance.

>

> I'm not Carl, and I don't know what he meant by "embed"... but I am

> interested in the ways you would value one or the other of the following:

>

 Put the object-oriented class


> library on a server running some middleware communication protocol and

> access it through COM, CORBA, RMI, etc.

>

> I find that a very large part of software development these days is done

 in


> the second model.  In that model, you choose a database based on the

> features it provides for performance and the ease of creating a data model

> to represent an existing data model expressed as a system of classes.  If

 an


> OODB can do that, then it can do that.

>

> Furthermore, it's simple to make a transition, in the second case, from

> using a database privately within one application, toward storing the data

> centrally for several applications.  All that needs to happen is for the

> data access classes to be relocated to a different, remote server.

>

> Chris Smith

>

>