I hear a LOT of developers refer to what are essentially N-Layers as “N-Tiers”. This kind of bugs me a little when I see or hear it from developers.
First of all, they are not even close the same thing, and it’s important as a developer to get this straight so that you are using the terminology properly. The difference is simple but very important when you’re talking about your applications. They should not be loose terms and intermingled as about probably 90% of the developers out there that I’ve worked with seem to do.
Take a look at a good article I’d like to surface from David Hyden about N-Layers and N-Tiers. Make sure you know what you’re talking about at work or in interviews both for an interviewer doing the interview or potential interviewee. It’s important especially in architecture that you know the difference here if you are going to be talking about them to your colleagues, subordinates, or potential employers.
Web Applications: N-Tier vs. N-Layer
Layers: This is how you are structuring/organizing your actual code and how you are forcing separation of concerns…design patterns
Tiers: Is your physical separation/location of your code & across process boundaries (physical servers which are running your application’s processes, etc.). It has nothing to do with naming your code layers
With that said, when naming your layers in .NET solution you should not use the term “Tiers” in the name. That’s not a Tier. It’s a Layer of Code. Use the proper term “Layer”. Use a proper naming pattern with the proper term.
So for example in a typical .NET solution I see this an awful lot and it’s not right (.sln):
Incorrect
AppName.DataTier.csproj
AppName.BusinessTier.csproj
AppName.Web.csproj
AppName.ServiceTier.csproj
Correct
AppName.DataLayer.csproj
AppName.BusinessLayer.csproj
AppName.Web.csproj
AppName.ServiceLayer.csproj
Print | posted on Saturday, October 11, 2008 12:04 AM