ASP.NET – Difference Between 3-Tier Architecture and MVC

asp.netasp.net-mvc

I would love to know how the 3-Tier architecture differs from MVC (Model, View Controller) in ASP.Net as it seems to me that the same architecture applies.

In 3-tier we have User Services Layer, BusinessLayer and DataAccessLayer, on the other hand we have Model, View, and Controller. This seems same architecture to me.

Can anyone explain if what really differs of the two architecture, how each layer differs to each other?

Best Answer

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:

Models
- 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.

Related Solutions

Web-development – Why decouple view and controller (web)

The reason why they are generally decoupled is because you want your view to use a controller in order to get at your model. But the architecture should allow you to replace one view with another one without having to change business logic (i.e. object model or how those objects are retrieved).

By not tying your controller directly to the view, later on it would me much more easier to add other functionality like import/export which can use the controller/model directly without having to rely on any UI.

Another advantage of pushing as much code as possible out of the UI is because UIs are much harder to unit test than business layer behind them. By separating as much as you can out of the view itself, you can write much more unit tests to ensure your controller/model and application logic are correct.

ASP.NET MVC – Role of ViewModels in MVC and 3-Tier Architecture

main MVC project, where M of MVC was moved to Data Access Layer

Common misconception. The M of MVC has nothing to do with data, despite the many examples and tutorials that claim so.

M is your ViewModel and should reside in your MVC project. The ViewModels you have in your BLL are actually to be named DataContracts or BusinessModels.

In your controller you have something comparable to this:

Get(id):
    dataContract = _service.Get(id);
    viewModel = Map(dataContract);
    return viewModel

In your service, something like this:

Get(id):
    dataModel = _dataAccess.Get(id);
    dataContract = Map(dataModel);
    return dataContract;

And in the DataAccess, you perform the proper joins according to the object requested. You are however of course free to add custom methods to your DataAccess when required, so your service can call those methods:

GetWithBars():
    dataModels = _repository.Query("select from foos join bars");
    return dataModels;