What does n-tier mean to you?

Question

I have noticed over the years that different developers have different criteria for what constitutes a tier in the development of an n-tier system so I was curious about what the consensus is here at stackoverflow.

Is separate logical layers sufficient to call it a separate tier or does it have to be deployable on a separate server (physical or virtual) in order to call it a separate tier?

Let me phrase the question a little bit differently. If the calling mechanism can only be in process, thread local, or apartment local, then is it possible to claim that it is two different tiers depending on how the classes are organized into libraries or packages?

Answer 1

I always believed a tier is any physical separation in an architecture, that means, a machine. I found that these guys think the same lately, it's a very good book.

But thinking well after reading the other responses I agree with Garry on that.

Answer 2

A separate logical layer is enough for me to call it a tier. It doesn't necessarily have to be on a separate server but the defined separation from other layers certainly makes it possible.

As an example we used to have what I would call a 3 tier system (db, dll, asp pages) running on a single server. By some definitions this is a single tier system. We now have the database running on a separate server, the only change required was a connection string but now this would be a two tier solution?

That is why I feel the concept of a tier is more about the ability to run them on separate machines rather than actually having to. It just seems more consistent to me.

Answer 3

The concepts of layer and tier are often used interchangeably. However, one fairly common point of view is that there is indeed a difference, and that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure

Ref.

Answer 4

For me, physical tier means part of the system, designed to be run on different physical machine. Yes, you can point your db connection string to another server at any time, but if your DAL is too chatty, has n+1 and unbounded record set problems, than network latency will kill you really fast.

Logical layer, on the other hand, supports virtues of separation of concerns, cohesion and coupling. Strictly it doesn't even have to be in separate assembly - namespace will do the trick. Just do not call classes you know you shouldn't, NDepend help you.

Answer 5

Layers are a mechanism for minimizing coupling; they are logical. Tiers are designed to maximize performance or negate security risks; they are physical. They really aren't them same and I'm not sure why people try to use them interchangeably.

The vast majority of web applications are 3 tier by default (browser, web server, database server). The majority of intranet apps are 2-tier (client, db server). But in either case I build a UI layer, a business layer, and a data layer. They have separation of concerns and help me structure my code for maintainability. Also in either case I usually end up deploying them all on one box; web server or client workstation. So the layers and the tiers don't even match up.

Answer 6

i would concur with Garry Shutler but add that many tiers might also exist in a single process/thread or even the same assembly. more important than the physical (hardware, executable isolation, or binary isolation) separation is the layout of the code for the developer (IMHO). as in with a aspnet app: the same one dll could have all three tiers in it: data access, domain and presentation.

Answer 7

I would have to say that the definitions need to be hammered out. I typically think of a tier as a logical separation of functionality and responsibility and a layer as the requirement or ability for a physical separation. Some layers may have multiple tiers and some tiers may span layers. I typically use a service layer tier that has the ability to provide physical separation if necessary and/or desired via configuration.

So, follow up question/comment. If there is a bunch of logic (business or otherwise) in stored procedures in your database, should that be considered a tier as well? What if you are utilizing features of your database engine like Service Broker for Microsoft SQL Server? That can be viewed as having two tiers itself.

Also, background services and/or daemons, are they a separate tier and/or layer or do they belong to an existing one?

Answer 8

Look at the history of the term "tier" in computing. No one said 1-tier computing on desktops/minis/mainframes. No one said 2-tier computing during the client-server days. 3-tier became the architectural moniker for client-server plus middleware in between (message oriented middleware and transaction brokers). I think n-tier was popularized along with another term "EAI - or Enterprise Architecture Integration". It was precisely the same idea as service-oriented architectures, except most of the vendor implementations were either proprietary, standards based but very expensive, or both. After XML-RPC, SOAP, and REST come along they call it "Web Services" and then apply the EAI principle behind it and come up to SOA - Service Oriented Architecture and Enterprise Service Bus.

My point is that none of these terms implied any physical separation... it was always about the logical separation of functionality. It just so happened that many of these logical application layers were designed to be stateless so that they COULD be physically separated for the purpose of horizontal scalability.