Tuesday, January 25, 2011

Thoughts on n-Tiered Programming

One of the problems that I had when first learning Object Oriented Programming was that the examples shown to illustrate concepts were so basic that they made no sense.

Why add piles of seemingly needless complexity when there were much easier and more straightforward ways to program solutions?

Why code interfaces that didn’t seem to add anything but more programming work and confusion?

Why create multiple Layers when all I was doing was passing unchanged values down the chain?

A lot of it started to make sense when I started doing things that were more complicated.

If the data does not change as it is passed from one layer to the next, having multiple layers doesn’t seem to make sense.

However, imagine a more usual scenario where the way your data is stored in the database does not match what is displayed in the UI.

Then it starts to get interesting.

I find it helps to think of n-tiered programming this way: The BusinessLayer translates between the data in the database and the data in the UI.

I usually have a more or less one to one correspondence between the data in the database and the objects which are created in the DataLayer and passed back and forth to the BusinessLayer.

I usually have a more or less one to one one correspondence between the data in the BusinessLayer and the data in the UI.

The BusinessLayer is where the translation happens. This is whether retrieving data from the database to display in the UI, or collecting data entered in the UI and storing it in the database.

(My other layer is an EntitiesLayer. I contains classes with properties to store the data for passing around.)

No comments:

Post a Comment