For asp.net mvc is this a three tiered solution?

Question

I am a asp.net mvc programmer and if I want to start a project I do this:

1. I make a class library named Model for my models.
2. I make a class library named Infrastructure.Repository for database processes
3. I make a class library named Application for business logic layer
4. And finally I make a MVC project for the UI.

But now some things are confusing me.

Am I using 3-tier programming? If yes so what is n-tier programming and which one is better? If no so what is 3-tier programming?

Some where I see that the tiers namings are DAL and BIZ.

Which one is correct according to the naming convention?

Answer 1

This is not a complete answer but it addresses one important point. Namely the difference between layers and tiers.

"It is important to understand the distinction between layers and tiers. Layers describe the logical groupings of the functionality and components in an application; whereas tiers describe the physical distribution of the functionality and components on separate servers, computers, networks, or remote locations. Although both layers and tiers use the same set of names (presentation, business, services, and data), remember that only tiers imply a physical separation. It is quite common to locate more than one layer on the same physical machine (the same tier). You can think of the term tier as referring to physical distribution patterns such as two-tier, three-tier, and n-tier..." for more see: MSDN-Layered Application Design.

Answer 2

As an amendment to the above answer (and a bit of a history lesson), "3-tier" and "n-tier" are the same where n=3. Back in the dark ages, application code and data were all in the same assembly (and "computing machines" were the size of rooms). That quickly changed, and "data files" were invented, creating a two-layered (still single-tiered) architecture. Some other things happened, and eventually the RDBMS came along, which was housed on its own computer, and the age of "client-server" computing was born.

Once the concept of separating the concerns of "program logic" (which included presentation-, business-, and application-logic in today's parlance) from "database logic" (persistence) was digested, business and application logic was moved to a "middle-tier", and suddenly we had "three-tier computing". It spread in the early nineties, and coincided with the explosion of the Internet and the World Wide Web.

From three-tier, it was a short logical leap to spreading things across many layers, and separating those layers across many execution environments, sometimes for security, other times for maintenance, often for performance. Tiring of the idea of having to describe things in quickly-increasing numerics, the phrase "n-tier" was born, and really describes any application architecture that spreads itself across multiple execution environments.

Note that today, with virtual machines, multi-core processors, and parallel computing, it's hard to say what code is running on what discreet processor, or how its separated from another "layer" on another "tier", but we like to put things in containers, whether or not the container has any real boundaries.