RE: Picking the Tools -- Marrying processing models to data model s

[Jeff Lowery <jlowery@scenicsoft.com>]

You know, somehow this thread had degenerated into a data-centric vs. OO
debate, and it's besides the point.

Look, I know I have a data model inside an object hierarchy. How do I know
this? Because everytime I have to store the objects' data in a database or
serialize it out to a file, I have go in, read the code, write code that
navigates all the get() functions, repackage the data model in some other
form, and write it out. Hopefully, I'll have the constraints in my database
or XML Schema match the constriants placed on the original data model
through the code written for all the set commands that populated it in the
first place.

What would be of great benefit is if I could 
1) have the objects internal data model made more obvious
2) have those constraints that can be written declaratively done so

This is all just objects, done differently. I won't say 'refactored' because
people will spit on me. But their are data models there, buried in all the
class hierarchies ever written; don't lie to me and tell me they're not. 

And yes, there is one of them, albeit representable in a thousand different
ways, one of the worst ones being through an OO langauge (as they currently
are designed).