What are the benefits of MVC architecture over N-Tier architecture

15 down vote accepted


N-tier architecture usually has each layer separated by the network. I.E. the presentation layer is on some web servers, then that talks to backend app servers over the network for business logic, then that talks to a database server, again over the network, and maybe the app server also calls out to some remote services (say Authorize.net for payment processing).

MVC is a programming design pattern where different portions of code are responsible for representing the Model, View, and controller in some application. These two things are related because, for instance the Model layer may have an internal implementation that calls a database for storing and retrieving data. The controller may reside on the webserver, and remotely call appservers to retrieve data. MVC abstracts away the details of how the architecture of an app is implemented.

N-tier just refers to the physical structure of an implementation. These two are related because an MVC design is often implemented using an N-tier architecture.


A 3-tier application it's deployed in 3 different processors/processes: such division is, most of all, physical (so watch your frequency of tier-crossing bcs it could affect the application performance, despite its multiple benefits). Usually the tiers are:

* The Front-End environment (typically a browser, a desktop application in a desktop terminal)
* The Middleware (an application server usually accessible thru a web protocol-based process)
* The Back-End, ranging from databases to large mainframe environments

In UML terms, a 3-tier application is better depicted with a Deployment diagram

The MVC architecture pattern establishes a division of responsibilities between components at a use case level, without mentioning physical boundaries (in deployment terms). Here you can find

* The Model, which represents the present status of the domain entities (without specifying where is that status, whether in memory, whether in a database, XML files set or a mainframe system)
* The View, responsible to capture user input and to display outcomes based on the Model status
* The Controller, which reacts to events generated in the View, motivating changes in the domain status (I mean, changes in the Model). Changes subsequently displayed in the View

In UML terms, the MVC architecture pattern is well depicted with a Sequence Diagram



So, as you can see, both models decompose applications from different perspectives and, sure, you can have both models present in a same application.

solution by:

Rajesh Rolen