[
Lists Home |
Date Index |
Thread Index
]
On Tuesday 22 October 2002 20:03, Jeff Lowery wrote:
> This maybe somewhat OT, but I need my little rant for the day:
> > Nobody's yet given a good reason why data encapsulation is bad.
>
> How 'bout: "Data model encapsulation is bad"?
>
> The problem is that current data encapsulation schemes coincidentally hide
> the underlying passive[?] (how about persisted?) data model. I think it's
> possible, however, to make a data model explicit while keeping it's data
> encapsulated.
>
> On the one hand, I like data binding technologies because they separate
> data model from process model, while keeping data encapsulated; on the
> other hand, you still get physical data model mismatches that are hard to
> reconcile satisfactorily.
>
> What would help (this is an old saw of mine) is if classes and there
> methods were loosely coupled to a schema and its data. This would make
> integrity checking on the data alone easier, because a lot of it can be
> declared, rather than coded. (I miss my old 4GL <sniff>.)
Ever played with Dylan, CLOS, or any other systems with generic functions
(aka multimethods)? That's a looser binding between classes and methods than,
say, Java provides, and I do like it!
> It would also make model-to-model mapping quite a bit easier, since you're
> operating at a higher level of abstraction. In other words, the object data
> schema would not have to be explicit about implementation; it may say:
> these sets of value pairs have lookup capability on the first value of each
> pair; the implementor could decide which collection class to use to provide
> that capability. That schema information would also clue in the database
> developer to add an index on the appropriate column in the appropriate
> table.
Yep!
ABS
--
A city is like a large, complex, rabbit
- ARP
|
