> -----Original Message-----
> From: Daniel Rall [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 22, 2001 11:16 AM
> To: [EMAIL PROTECTED]
> Subject: Re: query proposals
>
>
> Jason van Zyl <[EMAIL PROTECTED]> writes:
>
> > >> When I first started working with Turbine (around last
> > >> December) I remember some other discussions about the
> > >> relative merit of Castor's persistence layer
> > >> vs. Torque. As I recall, the primary complaint about
> > >> Castor is that there is a rather complex mapping
> > >> required between the object model and the data model.
> > >> That's a rather fundamental component of Ambler's
> > >> design, and it's exactly what allows the object model
> > >> to vary independently from the data model.
> > >>
> > >
> > > I would put it like this: A lot of flexibility for a huge
> cost with
> > > questionable benefits.
> >
> > Again I disagree 100%, the benefits are not questionable at all. The
> > separation is critical for a large project to succeed. I
> think most of your
> > experience lies in the data model realm which is totally
> fine but I think
> > you're eclipsing the value of the separation because you
> might not have seen
> > the benefits first hand. The tool should accommodate the
> simple and complex,
> > but more often things tend to get more complex than simple :-)
>
> I agree that the separation of data and object model is critical for
> enterprise-level projects. However, the majority of projects are not
> of this level, and thus do not require the added flexibility that such
> a mapping provides. In the simple/usual case, use of the peristance
> tool should be as easy as possible.
>
> An extremely user friendly way to handle the simple case would be to
> have the persistance tool default to generation of the mapping between
> data and object model (functionally what Torque does now in an
> inflexible style), but still allow tool users to provide their own
> mappings to handle the more complex case where data and object models
> are at a disconnect (which is usually the case when dealing with
> disparate enterprise data sources).
I agree. The right way to go would be to have more flexible code generation
with a number of optoins.
If that is not enough, it seems that you just need to map generated OM to
your target OM with some glue code which 1)seems simplier 2) cleaner (you
are working in a homogenious environment) 3)is apriori more flexible than
any mapping tool can possibly give you.
>
>
> Daniel
fedor.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
