“N-tiers” Application

What is meant by “N-tiers”

The N in “n tiers” refers to the number of tiers. A very common value for “N” is 3 (in  figure 1) comprised of three tiers of user interface or presentation, business logic and data access logic when applications behavior is split among multiple tiers these tiers are said to be logically separated. In some cases the separate tiers are physically deployed to different devices or process boundaries on the same device in which case there is physically separated as well. Is not required for separate layers to be deployed separately but they may be, likewise it’s not required that the separate layers be developed independently of one another this approach means it's possible for this to take place in this way you can allow for larger teams to work together concurrently or to have multiple teams working on separate parts of large application.

Generally tiers and layers are used interchangeably from one another however, sometimes use one has a more specific meaning in the case of layers often used to apply specifically to a logical structure of the application, likewise the tiers of an application frequently are used to refer to just the physical structure of the system architecture or infrastructure. In many cases you can refer to an application as N-tier application even if it is only deployed to a single machine and it’s also not uncommon to talk about the different layers of an application when in fact these layers are deployed to different physical tiers.

Logical vs. Physical separation

 The logical separation of concerns is expressed in the source code of the application the code organization and design should reflect the layers that are in use at a minimum individual classes should not include responsibilities that correspond to separate layers and typically each layer will have its own namespace assembly and project in the solution. The logical separation of an application across layer boundaries represents a software design patterns. The physical separation of the application generally refers how it’s deployed. It’s possible  to have logically separated applications  that is physically deployed to a single location, for instance web application with separate assemblies for business logic and data access all  of which deployed of the same “/bin ” folder on a single Web server. However it’s possible to separate these assemblies and deploy them to different physical locations whether on a single device or on separate machines the physical separation of the application across process boundaries and/or devices represents software architecture decisions. Generally the physical separation and the logical separation are described together. In other words you should have a logical separation in your software if you are foreseeing the need to have physical separation in your deployment.

Common mistakes to avoid when designing n-tiers applications

      1.     Tight coupling

Designing your applications in tightly coupled way with in mind that will not evolve.

      2.     Assuming Static Requirements 

Making an assumption that requirements will remain static especially when considering the client as trusted and the mid-tier service assumes the client will be implemented using a particular technology. 

      3.     Mishandled Concurrency

Designing your applications with optimistic concurrency as a choice

      4.     Stateful services 

Keeping context around across multiple service calls.

      5.     Two Tiers Pretending to be Three

 Trying to expose the database directly to the client without  the  mid-tier 

       6.     Undervaluing simplicity 

How to create the most carefully, multi-tier fully separated, re-validating, super design that you come up with. This latest mistake will take you away from the most important goal which is delivering value to your users.  All what you  need is to fix  your goals  and consider whether you are going to need n-tier requires, in other words apply the KISS principle  will always be great thing.