LLBLGen Pro Team
Scheveningen, The Netherlands
What is n-tier development?
N-tier development is one of the magic buzzwords introduced in the late '90-ies of the previous century, to describe a method to build applications by 'stacking' layers of logic on top of each other. Microsoft adapted this model and called it 'Windows DNA', which stands for Windows Distributed interNet Application Architecture.
N-tier applications consist of so called 'tiers' or layers. Each tier has a well defined set of functionality and acts as a 'black box' for the other tiers in the application. This way, the layer on level B, which lays on top of layer A and below layer C, uses layer A to receive services and provides services to layer C, the same way A provides services consumed by layer B. The reasons for the separation of an application in tiers are:
Because each layer has a well defined role in the total application, the system designers as well as the developers know which functionality should be implemented, or is located, where.
Because each tier provides a service to the layer(s) on top of it, different layers or tiers or even complete other systems, can use that particular layer to provide some services to them. This is the basis of the Webservices idea.
By defining parts of an application's logic as tiers, you can hide the way that tier provides its services to the rest of the application. This is particularly useful when the application has to grow in functionality. By keeping the interface of the tiers consistent (or at least backwards compatible) the users of those interfaces, other tiers, will keep working when the tier's inner logic itself is updated or even totally rewritten.
Because the tiers are separate units, you can decide to run each tier in an application on different machines, to keep the system scalable when the load on the application grows. If an application consists of one big executable, it's hard to chop it up into separate blocks and run each of them on different servers or even clusters of servers.
Since the functionality can be reused, it can also be centralized, so instead of storing all the logic in one big client and installing that on hundreds of machines, you can now store all the logic in one tier on a central server and make the clients connect to that tier on that machine to consume its services. This way a single place of functionality has to be controlled and maintained. The extra bonus of this is that the databases behind that centralized tier are also shared among those clients, which means that database-redundancy and the unavoidable inconsistency between these redundant databases are history. This is the main goal for Webservices.