This question already has an answer here:

I have a software engineering course project that we should design a web application, so I've decided to read about software architecture patterns.

I've read a lot about what is MVC and its structure, also I know about advantages of breaking an application into layers.

But I can not find an answer to this question, so I appreciate anybody who can tell me:

Where should we not use MVC pattern in a web application?

marked as duplicate by GlenH7, gbjbaanb, gnat, Thomas Owens Apr 28 '15 at 18:56

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

up vote 16 down vote accepted

In my experience, a web application would have to be trivially small to not benefit from the organization and decoupling that MVC provides.


Perhaps a bit of explanation about the MV* family of architectural patterns is in order.

The MV* patterns concern themselves primarily with the User Interface. Their primary purpose is to provide decoupling between the UI and the rest of the application.

In Winforms and other event-driven UI, we create a user interface by inserting objects that represent form elements such as text boxes into a Form container, and then attach events to those objects (such as Click or LostFocus) to perform actions in code.

enter image description here

I've drawn a thick arrow between the boxes to represent the fact that both data and commands are passed back and forth; this creates a user interface that is tightly-bound to the rest of the application. Anyone who has ever built an application this way knows that it's difficult to make it large, because you quickly end up with a plate of spaghetti code.

To solve this problem, we add a Presenter (sometimes called a Supervising Controller) to the mix, creating Model-View-Presenter. This arrangement pushes most of the UI logic out of the View, and into the Presenter, allowing for better maintainability.

enter image description here

Notice that I've drawn a thin line between the Model and the Presenter, indicating that only data is passed back and forth, not commands. This provides some decoupling between the Model and the View.

Model-View-ViewModel is very similar, except that there's a ViewModel instead of a Presenter. This arrangement is seen most often in Windows Presentation Foundation and in Single-Page Web Applications (SPA) using an MVVM framework such as Angular. In addition to command and control, MVVM also concerns itself specifically with data binding.

enter image description here

Model-View-Controller is primarily associated with web applications. In MVC, commands aren't routinely exchanged between the Model and the View. Instead, the View is POSTed to the Controller using an HTTP verb, and the controller decides what to do with it. Most of the domain logic is pushed back into the model.

enter image description here

Because MVC still binds the view rather tightly to actual domain objects, you can insert a View Model to get some additional indirection.

enter image description here

This View Model is not a command layer, like it is in Model-View-ViewModel; it's simply a data translation layer between the model and the UI. A good example of this would be a ViewModel for an invoice, which would contain everything that you need to display and update an invoice, such as names, addresses, and invoice line items. This data would then map to actual Model domain objects, such as Customers, Products, Pricing, etc.

When to use them?

When you need them for the purpose that they serve: to decouple the UI from the rest of the system. The flavor you use will depend on the kind of web application you are building. If your pages are mostly being generated server-side, you will use MVC. If your pages are being generated mostly on the client, using Javascript (as in a SPA application), you will use MVVM.

Not the answer you're looking for? Browse other questions tagged or ask your own question.