What Is Difference of Developing a Website in MVC and 3-Tier or N-Tier Architecture

What is difference of developing a website in MVC and 3-Tier or N-tier architecture?

They're pretty much the same, however in 3-Tier, the top level (presentation) never directly communicates with the bottom layer (data persistence).

In model-view-controller, theoretically the Model is supposed to 'notify' the View that it has changed so that the View can update. However, this is usually not an issue in most web applications because they are stateless. I'm not sure if any well-known PHP MVC architectures have Views that directly communicate with Models or vice versa, but if they don't it would be correct to say that they are in fact 3-Tier.

Wikipedia says:

At first glance, the three tiers may
seem similar to the MVC (Model View
Controller) concept; however,
topologically they are different. A
fundamental rule in a three-tier
architecture is the client tier never
communicates directly with the data
tier; in a three-tier model all
communication must pass through the
middleware tier. Conceptually the
three-tier architecture is linear.
However, the MVC architecture is
triangular: the View sends updates to
the Controller, the Controller updates
the Model, and the View gets updated
directly from the Model.

Source: Wikipedia: Multitier architecture

what is the difference between 3 tier architecture and a mvc?

Comparison with the MVC architecture

At first glance, the three tiers may seem similar to the
model-view-controller (MVC) concept; however, topologically they are
different. A fundamental rule in a three tier architecture is the
client tier never communicates directly with the data tier; in a
three-tier model all communication must pass through the middle tier.
Conceptually the three-tier architecture is linear. However, the
[model-view-controller] MVC architecture is triangular: the view sends
updates to the controller, the controller updates the model, and the
view gets updated directly from the model.

Source: http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture

MVC Vs n-tier architecture

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 sometimes confused because an MVC design is often implemented using an N-tier architecture.

Main Difference Between 3-tier & n-tier Architecture in .NET?

3-tier architecture is general architecture in software development and it consists of

• Presentation layer (client browser)

• Application or Business logic layer

• Data Layer

n-tier architecture in .Net

The main difference is that n-tier arch got 2 extra layers. Example on data layers one part of developers are SQL developers whose work on DB server (making DB structure, writing Stored procedures and so forth), and .Net developers whose work on consuming that stored procedures and making abstraction ( implementing repository pattern)...

Hope this help you.

What is better: Developing a Web project in MVC or N -Tier Architecture?

They aren't mutually exclusive. The Model-View-Controller pattern is really a user interface design pattern, and it concerns logical rather than physical tiers.

I most often hear "n-tier architecture" used to describe the actual physical separation of an application's layers. For example, a system in which the user interface runs in one process, exchanges data with an application layer (perhaps via messaging or web services) that executes in another process (perhaps on another server), which in turn accesses a data layer that runs in yet another process (typically a database server).

This description can be particularly confusing because 'application logic' can mean multiple things: in an n-tier system it usually means business logic - as opposed to user interface logic (like which widgets are enabled when the user selects a particular checkbox).

For example, in an n-tier system, your presentation layer might call a web service method that accepts an item ID. The web service runs on a different server, where it performs complicated calculations and returns a price.

In a simpler architecture, your application might calculate the item's price in the same process as the user interface - though the pricing logic may be separated into its own logical layer (perhaps within library or executable).

I can't think of any current MVC frameworks that care whether their layers run in separate physical processes or not.

MVC application. How does mult-tier architecture fit in?

M) M is your model. This is generally living in your business layer or the layer just behind your presentation layer. Many people don't like the presentation layer to have any knowledge of the business layer though and so they further abstract that by having what is called a ViewModel. These frequently are DTO (data transfer objects) that loosely map to your Domain model. For me (.net guy) there are tools such as AutoMapper to make the conversion from Domain Model to View Model.

V) V is your view. The view is your presentation layer. This is the actual HTML or PHP code that the user directly touches and interacts with. The view should be as light as possible (meaning no logic if possible). Try to keep any sort of if/then type scenarios out of the view and stick to just displaying and collecting data. Present a ViewModel to your web designers so that they don't contaminate your DomainModel.

C) C is your controller. This is much like a co-ordinator. It takes data from your view and makes sure it gets to the right back end function/method for processing that data. It also co-ordinates data from the back end on it's way to the front end.

Where multi-tier design concepts come in is behind the Presentation layer (where is where MVC is primarily). When the controller is taking data from the view and passing it back to the back end it (if you follow DDD or Domain Driven Design) would pass the data to an application service (a class that co-ordinates back end matters). The service might further push the data into a Repository layer (which is a class that speaks to the database, filesystem, web services, etc. - any infrastructure stuff). DDD is a big topic but will get your head around the n-tier approach and how it works with MVC.

While researching this topic take a look at IoC (inversion of control), DI (dependency injection), TDD (test driven development), and as many patterns as possible (facade, factory, etc.).

I need some clarification on the MVC architecture and the three-tier architecture

1. MVC is mostly a pattern for the presentation layer, and it focuses on the interaction between the view and the controller. The model can be considered to be the components of the application that are responsible for maintaining state, including persistence.

   In a simple application the model might just be an LINQ-To-SQL model. In a large enterprise application the model might contain a data access layer, business layer, and a domain layer. The ASP.NET MVC does not restrict you to how the M should be implemented.

2. The Repository pattern is one way to implement the persistence part of the M. The ActiveRecord is another. Which pattern to choose depends on the complexity of the application, and your preferences.

   Take a look at Step 3 of the NerdDinner tutorial where they create a simple repository using Linq to SQL.

3. Linq to SQL will not be dead. Microsoft will still improve the core and add customer requests where it makes sense but Entity Framework would be the primary focus. Take a look at this post for LINQ to SQL changes in .NET 4.0.

   The EF can be used is a similar way as LINQ to SQL, but it is also more flexible so it can be used in other ways. For example EF4 will more or less support persistence of your own POCO objects in a more Domain Driven Design.

On Which Tier should user authentication should exist in n-tier website

There are quite a few similar questions here on stackoverflow, and just many answers. Here my view on the matter.

You have to separate the abstraction from the implementation.

The abstraction (an interface) defines the questions you need to able to ask to the authentication service. This interface is used by all other parts of your application that are going to use your authentication service. This means that your abstraction must be defined somewhere that can be referenced by the other parts of your application. My suggestion would be to put this in the business layer, since the methods in the interface (in other words the 'questions that you want to ask to the service') are usually business related. Another suggestion is to put it in a Core layer (if you have one).

That leaves us with the implementation of the interface. I would implement this in the easiest place that you can that works. Can you do it in the business layer, fine. Do you need to use the identity classes from MVC, good too, place it there. It doesn't really matter where you put it, since it isn't used directly.

Of course, to make this all work you do need to use a little Dependency Injection, to register your implementation for the interface.

N tier within MVC

MVC is a presentation pattern only, thus it only says how you should structure your presentation logic. It doesn't say anything about data access patterns nor how you structure your business domain.

I tend to structure my web apps in a web-project (MVC), a models (domain) project, and maybe a data access and/or services project depending on the app. I always delete my Models-folder in the web project as I don't want any of that there. All my domain models and view models live in the models project.

Regarding the controllers, a controller should only be a translator for what the user wants to do (the request) so the model and view can respond accordingly (the response). I.e. the controller should be so thin that you barely notice it. The controller should contain logic for choosing the model and what view to display. All other logic belongs in the model.

In addition, the view should only contain very simple presentation logic like ifs and foreaches, but the conditions should be prepared in the view model.

---

Related Topics