This is like asking what the difference is between an apple and an apple core. These two architectures aren't replacements for one another. I think a more accurate view is that the 3-tier architecture augments MVC.
The MVC Architecture
Models: These represent "stuff" in your application. This layer has gotten a little fuzzy in recent years, as I will explain later.
Views: The user interface. The thing the user interacts with.
Controllers: The programming code that responds to the user and to changes in the model layer
The 3-Tier Architecture
With the 3-tier architecture, you have layers with different responsibilities.
User Services: (or "services" in general) This layer is more about coordinating the retrieval and modifications of the "model" layer. Complex, multi-step actions get performed here
Business Layer: This represents the business rules etched into programming code. What "The Business" wants is enforced in this layer.
Data Access Layer: One or more classes responsible for accessing a persistent data store.
The only part of the 3-tier architecture that intersects with MVC is the "Business Layer". The "Models" in MVC and the "Business Layer" in 3-tier architecture are trying to achieve the same goal.
The "M" in MVC has gotten fuzzy
The "model" layer in MVC has expanded in recent years. From what I've seen, there are two, possibly three kinds of models:
Domain Models: These represent the "things" that "The Business" cares about -- the Business Domain. These classes hold data and all procedures that operate on that data in order to enforce business rules. Frequently Domain Models are tied to tables in a database. This seems to fit the "Business Layer" of the 3-tier architecture.
View Models: These are classes used to massage the data from the domain models into something more palatable to the view. This doesn't fit anywhere in the 3-tier architecture because view models do not implement business logic, nor do they provide any sort of service or data access.
Business Models: In complex applications, the need to decouple the Domain Model from the Business Logic arises. The Business Models contain data and procedures operating on that data to implement business rules, and the Domain Models are relegated to "Property Bags" -- objects that just hold data but contain no behavior. Domain Models become another form of Data Transfer Object between the database and the application.
Nowhere in MVC is data access mentioned. In some cases, you'll see that data access belongs in the "model" layer of MVC, which as we've seen is not a clear cut layer anymore. Really I see 3-tier architecture being paired with MVC to create a whole application. One augments or improves upon the other:
- Domain Models (MVC/3-tier)
- View Models (MVC)
- (optionally) Business Models (MVC/3-tier)
- Views (MVC)
- Controllers (MVC)
- Data Access (3-tier)
- Services (3-tier)
There is some intersection, but they are largely separate, and together are used to decouple and isolate various components of a larger system.