> From: Jim Cook [mailto:jimcook@xxxxxxxxxxxxx]
> Yeow!!!! Did someone hack into Mark's gmail account? :-)
As Mark pointed out, DP is neither good nor bad. There are certain
domains were DP makes more sense than behavioral OO. In fact, both
behavioral OO and DP might exist on the same project. I would recommend
a DP mindset when designing the database schema. The danger is that
folks tend to start with the data model and try to build an object model
on top of that! WRONG, WRONG, WRONG, WRONG, WRONG! (sorry, I got
excited).
The behavioral object model should be produced entirely independent of
the data model. And unless your application is a basic CRUD app for
maintaining database tables, it will probably not match the data model
except at certain key points.
For example, on a recent project I worked on, we had both a data model
and an object model. The data model flopped about as we kept switching
from a LDAP/Hierarchical model to a relational model. After failing to
make the hierarchical model work out, we decided on a relational model.
At that point, the relational data model went through major revisions
with entire tables appearing and disappearing and relations that kept
changing over the several months of the project. The entire data model
churned through at least 7 revisions before we finally settled on
something. (and the day before we cut the code for UAT testing, it
changed again! Minor tweaks are still being requested).
In contrast, the object model was designed early in the project. It
remained very stable with little change throughout the project lifetime.
In fact, we switched from a client only architecture to a client/server
architecture with only minor changes to the object model.
It is interesting the compare the object model and the data model. You
will find a couple objects with names that are similar to table names in
the data model, but very little direct correlation.
Why was the behavioral object model so stable when the data model was in
a constant state of churn? Probably several reasons, and I'm not sure
and understand the reasons fully. One reason is that the object model
was based on the abstractions needed to perform a particular business
related job. The business needs of the job didn't change over time, so
the abstractions were fairly stable.
The data model, in contrast, was /not/ based on abstractions, but was
involved in the nitty gritty of the concrete implementation details of
the data store. This piece of data goes here, and that piece of data
goes there.
Fortunately, for this particular application, the point of contact
between the data store and the object module was a single SQL query. So
every time the data model flipped, I just needed to update one method in
one class.
The next phase of the project will be building the web based admin tool
that manages the data model we created. The object model for /that/
portion of the project will probably much more tightly coupled to the
data model.
--
-- Jim Weirich / Compuware
-- Strategic Infrastructure Development
-- http://fwp-st.fmr.com/sid
|