the tiers are independent of each other.
The data layer for example is the one and only SQL specialist, completely separated from the business objects.
This independence is widely accepted.
The implementation of such separation is more tricky.
|Monday, 30 August 2004
DataRetreiver:Tabel = 1:1?
Many IT specialists create for each table a data object,
one to one.
That is a pity.
- The object layer must address the right data object, so know who has the knowledge.
- When the database structure changes, the object layer must address another data object.
So, the independence flies out of the window.
- In addition, it is tricky to select a data object for joined queries.
Object:Tabel = 1:1?
Things can get worse:
Business objects with a one to one mapping to tables, to keep things consistent.
Those who know the difference between
the half brothers Class and Tabel,
sees how ridiculous such 1:1 mapping is.
As a side effect you hear the irrelevant discussions between OO-ers and data-specialists.
It seems forgotten that the half brothers have a common mother: a conceptual model.
Please keep this difference.
Ignore those differences and the reason for separate layers evaporates.
How to keep the layers independent?
The data layer may change, as long as the
- Create 1 big data class and call him
Abraham for example.
- Business objects just call the right,
method, without knowing where Abraham gets his wisdom.
- The data layer returns raw data.
For SQL this can be a result set, with agreed aliases for each column.
The real column will be irrelevant for the business layer.
- The business layer translates that raw data into objects, possibly of different classes.
contract remains untouched.
So, it is for example possible to implement the following changes, without the object layer noticing a difference:
Those who know Abraham will get knowledge, though from an unknown source.
Those layers will be truly independent.
That is nice, as Abraham may find other sources without his customers noticing a difference.