Is N-Tier Architecture only the physical separation of code or there is something more to it?

Question

Is N-Tier Architecture only the physical separation of code or there is something more to it?

What sorts of coding do we put in Presentation Layer, Application Layer, Business Logic Layer, User Interface Logic, Data Access Layer, Data Access Object,?

Can all the layers mentioned above give a fully functional N-tier architecture?

One case:

Whenever a user clicks a button to load a content via AJAX, they we do coding to fetch a particular HTML output and then update the element, so does this JavaScript coding also lie on a different tier? Because If N-tier Architecture is really about physical separation of code, than i think Its better to separate the JavaScript coding also.

Answer 1

Tiers and Layers are completely different things.

N-tier is less about code separation and more about scalability. The idea being that you can easily scale out different "tiers" as necessary. Most websites are 2 tier: web server and database server. Sometimes they go to 3, with a Service Oriented Architecture.

Layers is all about code separation and reusability. MVC is a good example of layered code.

Beyond all of that and before you go happily putting up barriers between different portions of your code, you really need to ask yourself two questions: What are you Separating and Why are you Concerned about it? If you can't give rock solid answers to both of those (particularly the second), then I'd say stop what your doing and back away from the keyboard. And by a rock solid answer, I don't mean "because bob said this is the way it should work."

Take the time to really understand what is going on, how both the code and your sanity will be impacted by putting up these barriers. If they help, great; if they don't, well..

Answer 2

The way I've heard the difference between layers and tiers described is that layers can be on different machines whereas tier may not (I have also heard the terms used in reverse). Thus, n-layer implies n-tier. The database server for example represents a separate layer but simply have a library of business logic that cannot be run on a machine separate from the presentation code is simply a separation of tiers. If the business logic is accessed through a service layer which could be hosted on a different machine than the presentation code, then it would, as the name implies, represent a separate layer.

N-tier would simply mean a separation of code into libraries that might still be required to run on the same physical machine. N-layer would represent a separation of code into services that probably run on separate machines even if it was possible to run them all on the same machine.

Addition

The Presentation tier would contain anything related to displaying the information to the user. In an MVC for example, that tier is subdivided into a controller which retrieves information from the business logic tier (model) and a view which displays the information itself. The data access tier would contain code used to retrieve information from the data layer. The business logic tier(s) would contain code the retrieves information from the data tier, processes that information into an object model that accounts for business rules and makes it available to tiers above it like the presentation tier.

The reasoning behind tiers is that they provide a degree of separation from the tier below. For example, suppose the data layer changed or more specifically, the database product changed. It would only require updating the data tier and not the entire code base.

Using the definitions I've provided, a standard database driven website for example with no calls to services really only has a presentation layer and a data layer (the database) even if it has multiple presentation tiers, middle tiers, and a data tiers. If you have service calls, depending on where they are called, they would represent another layer.