Sunday, August 28, 2011

Layers versus Tiers

There is one question that is often confused in design/architectural considerations namely - Tiers versus Layers.
Here we try to analyze the difference between the 2.
Layers: A Layer is considered to be a discrete, orthogonal area of concern within an application. A layer generally would be a logical section of the code that deals with unique features. For example a persistence layer would deal with all the code related to database operations in a section of the code. This way it is easy to divide the work and isolate problems. If we have any change related to a database we know which part of the code gets affected and we can isolate the area of concern.
The other features of layers are:
1. Layers are conceptual boundaries and are not necessarily physically isolated. More often than not the layers would be placed in the same VM.
2. Thinking in layers can help conceptualize the flow through an application and help in more organized design.

Tiers: By contrast a tier is best thought of as a physical deployment of the layers. Thinking in tiers is more related to system administration and architectural decision making where it helps us decide what would be the different server, V.M. and other hardware requirements. Mostly multiple layers are mapped onto a tier.

The best example of a tiered architecture is a 3 tiered architecture where we deal with client-server-database.
In contrast the 3 layered architecture deals with the 3 layers in the form Controller-Service-DAO layers at the server side.

No comments:

Post a Comment