> Persistence has never been, and probably never will be, truly
> "transparent". You yourself said on page 53 of your JDO book that
> "it is necessary for you to understand the intricacies of JDO's
> persistent object model in order to apply the technology
> appropriately". I have found the same to be true over the years for
> TOPLink, the OMG's Persistent Object Service, and Gemstone (both /S
> and /J).
> Therefore I think any discussion of implementing domain models is
> nicely complemented by discussion of how to persist domain models.
This is an important topic.
My experience was best with Gemstone/S (before it needed an "/S"!). I
remember to this day getting the software from Tim Wrast, the salesman
in the PNW at the time. I was stunned.
I loaded it and started writing code with persistent objects right
away. There were no mapping issues, and moreover it wasn't for several
weeks before I went to Gemstone training courses. I was able to
continuously build up a multi-user domain model with the ease of
programming in a single user Smalltalk image.
Of course, later came the need to understand the nasty
intricacies. But the ability to get started right away with little to
no concern for those details enables "extreme" (shall we say) domain
modeling.
What tools other than Gemstone support this degree of rapid, multi-user
domain modeling today? Are TopLink or various JDOs so transparent out
of the box?
I don't do a lot of programming these days, but when I've picked up the
editor on a few prototypes recently I just used a directory of XML
files!
Combined with XPath, it seems to make an almost decent poor-man's
OODB at least for easy prototyping.
PatrickLogan
Absolutely. Just being able to map a set of domain model classes to a set of
relational tables, or whatever, doesn't impress me much. That's only the
minimum ante for an object persistence mechanism. It's not industrial-strength
until it has proven reliable scalable performant implementations of features
like caching with identity integrity and variable reference strengths, private
per-client-session transactional views of persistent objects, minimum-overhead
and minimally-intrusive dirtiness detection, proxying with variable reference
strengths, integration with XA-compliant transaction managers, etc. Most of
these are subtly inter-related.
I hope the day comes when there are more object persistence mechanisms available
which implement these features, and on which high-scale, high-performance
enterprise applications have been developed and are in successful referenceable
long-running production operation.
I'm responsible for an enterprise application with a domain model of 713 Java
types mapped to 424 tables and views, presented through 300+ JSPs. This
application has been in production on TOPLink for over three years, sees 1,200
logins and 30,000 page views per day, and enables my company's major primary
revenue stream. I'd guess it has probably cost my company over $500K in
cumulative payroll expense over the years to develop and maintain the relational
persistence of this domain model, and scalable performance is a constant concern
of mine as the chief architect. But, given the application's
mission-criticality, I'm squarely in the middle of Geoffrey Moore's adoption
curve when it comes to persistence technology.
> What tools other than Gemstone support this degree of rapid,
> multi-user
> domain modeling today? Are TopLink or various JDOs so transparent out
> of the box?
Speaking for TOPLink, the answer is no. It is not so transparent. It doesn't
sound like JDOs are either.
RandyStafford
Hello again Randy
> Speaking for TOPLink, the answer is no. It is not so transparent. It
> doesn't sound like JDOs are either.
JDO is not as transparent as Gemstone was. However JDO imposes fewer
constrains on the persistent object model than TopLink, and does not tie the
application to a relational storage paradigm. So as far as transparency
goes, JDO probably sits between those two. With JDO you get a standard
datastore-agnostic object persistence API with many of the features needed
for a good out of the box experience.
Additionally, using JDO in conjunction with an Object database affords all
the schema evolution capabilities that ODBMS developers have come to expect.
For relational users, tools are available that try to smooth this process by
generating as much as possible of the require SQL DDL automatically.
RobinRoosPersistenceAndDomainDrivenDesign is mentioned on: ThreadView
