Monday, 30 August 2004
In a 3-tier architecture 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.

DataRetreiver:Tabel = 1:1?

Many IT specialists create for each table a data object, one to one. That is a pity.

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.

The model->tabel mapping differs from model->class mapping. Please keep this difference. Ignore those differences and the reason for separate layers evaporates.

How to keep the layers independent?

Very simple:
  1. Create 1 big data class and call him Abraham for example.
  2. Business objects just call the right, encapsulated method, without knowing where Abraham gets his wisdom.
  3. 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.
  4. The business layer translates that raw data into objects, possibly of different classes.
The data layer may change, as long as the 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.

Till next nut,