Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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
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 "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:
There is some intersection, but they are largely separate, and together are used to decouple and isolate various components of a larger system.
No, they are not the same.
MVC is a design pattern for structuring user interface code. It could be used in a three-tier architecture, in which case the pattern would belongs in the user services layer. But it can also be used for the UI in an applications which is not three-tier - e.g. a calculator with no underlying persistence, and therefore no data access layer.
In a three-tier architecture with a MVC frontend, the domain objects used as the model would be the objects from the business layer, but the MVC pattern does not really specify what kind of objects the model is, only what their role in the pattern is. For example in the MVVM variant, the models are UI-specifc adapters on top of the domain objects. In this case even the model belongs in the user service layer.
I know there will be tons of different answers, but I'll give you my view on this.
It's the most famous answer in software engineering "It depends".
Essentially if you look at it, besides various implementation and theoretical differences these are very similar patterns with similar flows.
Where the it depends comes in is the application you're building, a simple webapp may have only an MVC layer talking through an ORM to the DB. A more complex one may have MVC handling the front-end in the User Layer, with more complex non-user exposed operations happening in the BL layer, with the data layer consisting of multiple sources.
