[
Lists Home |
Date Index |
Thread Index
]
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>.)
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.
So, if we could encapsulate our data while still making our object data
structures explicit, there would be a lot to gain in that particular
separation of concerns.
|
