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).
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
