Layers and Tiers

At times, people tend to use “layers” and “tiers” interchangeably when they talk of application architecture. These are really two very different things:

Layers are a means of logical separation, and are an architectural pattern to separate concerns. Typical layers are the storage / data layer, the data access layer, a business logic layer, and a presentation layer. When deploying an application, these layers might exist either on one machine, or on multiple machines.

When architecting the layers of an application, one must consider various factors:

  • What is this layer responsible for?
  • Will this layer translate to a tier at any point?
  • Are other applications expected to communicate with this layer?
  • What are the dependencies for this layer?

Tiers are the physical separation of an application. Typically, a regular web application will have a data tier which maps to the database, a business and presentation tier (potentially together) that map to the underlying business logic and web pages respectively, and a front-end tier that maps to the browser. There are scenarios wherein the business and presentation layers are split, so the business layer components reside on a separate node, and the web application itself resides on another node. Tiers necessarily imply layers, but not vice versa.

 While layer decisions are driven primarily by separation of concerns, a tiering decision is driven differently. In fact decisions around tiers need to be well thought-out, especially since physical tiers may result in a performance degrade, due to network latency, and marshalling / unmarshalling overheads. For the most part, having the data sit in a separate tier on a database server is fairly well accepted, but the decision of whether or not to separate web pages into a tier separate from business logic components is a question that is often debated. A few points that support this separation are:

  • If the web server is expected to serve up a large amount of static content, it is more feasible to scale out the web servers independent of the business logic processing, and hence keep them on separate tiers.
  • If the processing of the businss logic requires a significant amount of processing, and this acts as a bottleneck for the rest of the web page processing, then it is more feasible to scale out the application servers independent of the web servers, and hence keep them on separate tiers.
  • If the functionality encapsulated by the business logic components is expected to be consumed by clients other than the presentation layer, then it is better to have these hosted on a separate tier, and front-end it with a web service / WCF facade.
  • If there is a need to have more security for the business functionality, then it is better to host the businss logic components in a separate tier, and separate it from the web server using a firewall.

If, on the other hand, the intent is only to scale out, without a deep need to scale out business and presentation tiers independently, then keeping them in one tier is better: Consider the case when I have five machines, and I use all five to host both my presentation and business tiers. In comparison, if I use two of these for my presentation tier, and three for my business tier, then I still have the same compute power, but now have to contend with the additional overhead of marshal/unmarshal, and latency. I’m hence better off with the single tier in such a case.

All said though, while a physical separation improves scale-out capability and security, it does impose overheads due to the network. The design for tiers needs to take into account the communication between tiers – too chatty, and performance degrades rapidly. The choice of protocol is equally important – the protocol of communication should be the most lightweight, and be as native as possible – so if both the web pages and the business logic components are built on the .Net stack, then a NetTcp binding is more suitable than a Http-based binding.

One interesting point in this context is how WCF supports multiple bindings, as well as the capability to build new ones. A neat extension as been built in the form of the Null Transport channel. Using this, if I have the case wherein I start with wanting to keep the two tiers together initially, but have the intent to separate them later, then I use WCF, but with the null transport for communication. This allows me to get performance closest to an in-proc call, but also gives me the ability to subsequently switch to a different binding if needed. That seems the best of both worlds.


7 Responses to “Layers and Tiers”

  1. Soumen Says:

    I am going to design a heavy lodded shopping cart, I want separate ui,DAL,BAL in separate server,
    Let say UI is in this is the gateway server
    bal is in
    dal is in
    themes in
    images at

    so when call think of the system, all 5 server are acting to a single request
    So it is a distributed system of resources..

    How do i implement in dot net,

    • srinivasrb Says:

      If I understand this correctly, you have your presentation in one tier, the business logic in another tier, and your data access in another. The images and themes really are UI components, so you’ll want to have an overall page that brings together your shopping cart control, plus any additional themes and images together. The communication with the BL and DAL can be through the usual .Net communication mechanisms like WCF.

      That said, I don’t think you really want to split it up to that extent, since each split implies a performance overhead. IMO, you ought to consider the BL split, but ought to reconsider the DAL split. Please see my previous notes on the implications of separating into tiers.

  2. Sandeep Says:

    Nice write-up (too often, I hear ‘tier’ and ‘layer’ tossed around – this article clarifies a lot).


  3. Abhinav Bhatnagar Says:

    Nicely written !!

  4. Abhinav Bhatnagar Says:

    Can you please throw some light on Ajax enabled WCF Service with Auto Completion control. Can we place service in domain other than application domain or client code.

    • Srinivas Rao Bhagavatula Says:

      I would do the following:
      – Since the service is specific to your auto complete (and hence your presentation), consider this as separate from the (domain) model itself
      – These presentation services will then ride on top of your domain model
      – Since these will be consumed directly by the browser, you will want these deployed in the DMZ, which hence implies deploying on the same servers as the ASP.Net application
      – If you have also separated your business logic so that it runs on its own tier, then the path would be browser -> presentation services -> business services, and to ensure you have reasonable performance your presentation services (as also your ASP.Net code) would call your business services using an efficient binding like NetTcp.

  5. Abhinav Bhatnagar Says:

    Thanks for the reply !! Understood the concept.

    Another thing as i am new to WCF, I have 1 WCF Service having four service contract gives me functionality of Addition,Multiplication,Division and Subtract respectively and if expose 4 different endpoints at service(E1 FOR ADD,E2-SUB….So on…)

    Now question is at client i want my Client1 can consume only Add feature using E1 but cannot consume Multiplication thru E2.

    What i think for this….
    a) if i instantiate the my Service Contract which is interface thru the class which implements it , will give me only those operation contracts which are defined in that contract only…this is simple OOPs concept.

    b.) But at client side after adding the service reference WCF by default provides the ContractClients….which would provide the details of all Service contract which is even not related to proxy class contains all the information…Can we restrict the client at service…After adding Service reference is it possible to get only those information for web config which is required for that client….

    In short i am looking for client-Service security based SOA

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: