Why should I use an MVC pattern?

Question

It seems everyone doing web applications nowadays wants to use MVC for everything. I find it hard to convince myself to use this pattern, however. I understand the general idea is to separate the backend logic from the frontend that represents the program. Generally, it seems that the views always depend on the controller to some extent, which ends up depending on the model. I don't see what advantage adding the controller gets me. I've read a lot of hype about "this is the way applications should be designed", but maybe I still don't understand what is supposed to go where. Whenever I talk to others about MVC it seems everyone has a different idea of what belongs in what category.

So, why should I use MVC? What do I gain by using MVC over just separating the frontend from the backend logic? (Most "advantages" I see of this pattern are gained just by separating interface from implementation, and fail to explain the purpose of having a separate "controller")

Answer 1

Heh. Martin Fowler agrees with your confusion about MVC:

I don't find it terribly useful to think of MVC as a pattern because it contains quite a few different ideas. Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. If this doesn't cause enough confusion you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers.

However, he goes on to give one of the more cogent explanations of what motivates MVC:

At the heart of MVC is what I call Separated Presentation. The idea behind Separated Presentation is to make a clear division between domain objects that model our perception of the real world, and presentation objects that are the GUI elements we see on the screen. Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentations, possibly simultaneously.

You can read Fowler's entire article here.

Answer 2

I feel this depends much upon the problem you are tackling. I see the separation as follows:

Model - how do we represent the data? For example, how do I go from my objects to a persistent storage such as a DB -> how do I save my 'User' object to the database?

Controller - what am I doing? This is the action that's taking place, and what, on a conceptual level, needs to be carried out. For example, what stages do I need to go through to invoice a User? N.B. this may affect any amount of objects, but does not know anything about how they are persisted to the DB.

View - how do I render the result?

The problem I feel you are seeing is that a lot of web applications are a glorified CRUD (Create-Retrieve-Update-Delete) interface to a DB. i.e. the controller is told to 'add a user', and it then simply tells the model to 'add a user'. Nothing is gained.

However, in projects where the actions you carry out do not apply directly to changes in the model a controller makes life much easier and the system more maintainable.

Answer 3

You shouldn't.

Let me rephrase that. You should use an architecture that separates logic from your views. If needed, you should use an architecture that utilizes a controller (such as MVC) if there is logic required that doesn't necessarily fit into a model (such as, say, a tree traversal parsing URL chunks).

Coming from CI and Yii, I thought that having a dedicated controller was a really cool idea. However, when developing applications with proper RESTful interfaces, then the need for a controller to handle non-model-specific logic seems to lessen. Thus, when moving to Django and then Pyramid (neither of which follow the MVC architecture completely), I found that the controller was not actually a required component for the applications I was building. Note that both frameworks have "controller'ish" features, such as URL Dispatching in Pyramid, but it's a configuration thing, not a runtime thing (such as CController in Yii).

At the end of the day, what's really important is the separation of view from logic. Not only does this clean things up in terms of implementation, but it also allows FE/BE engineers to work in parallel (when working in a team environment).

(Side note: I don't develop web apps professionally, so there may be something that I'm missing)

Answer 4

Yes, the terminology on this is a mess. It's hard to talk about because you never quite what somebody means by the terms.

As far as why a separate controller, the reason might depend on which version of controller you are talk about.

You might want a controller because when you run tests the view has a bunch of widgets that you didn't write and probably don't want to test. Yes, you separated implementation from inheritance, so you can use a stub or mock to test other stuff, but when you test your concrete view itself it's harder. If you had a controller that didn't have any widgets running that same code then you could test that directly, and maybe not need to test the widgets via script.

The other versions are IMHO harder to show a concrete benefit for. I think it's mostly a separation of concerns issue - separate pure visual GUI concerns from logic that applies to the GUI but isn't part of the business model (things like, translate updates from the model into which widgets should be visible). But in practice the two classes are likely to be so tightly coupled (even if they communicate through interfaces) that it's hard to be overly upset at merging them into just a view, and just keep an eye out for ways the functionality might be more reusable if they were split.

Answer 5

Simply put: separation of concerns. Aside from all the talk about the "correct" way of doing things, having cleaner code, etc. you can just say that MVC allows you to more easily reuse your code. Basicaly you program your models and your controllers and you can use them indistinctly in a web app, a desk app, a service, anywhere without much effort.

Answer 6

Well the basic reason for using an MVC structure shows up in an industry setup, where a single work process, a single model is followed for the development of any application. So, in case, if the project moves on from one module of an organization to another, it is much easier to provide a better understanding of the work scenario. It incorporates clarity of work.
While you, as an individual would have a different approach for your application, you when working in a combined fashion with an associate, would first discuss and land upon a commonly agreed model by the two (you and your associate). And in such a case, it separates the responsibilities assigned to you and your associate respectively with a distinctive margin.

Answer 7

I think MVC is used just a buzzword by theorists that are managers. However, having said that, the current iteration of the web with HTML5 prevalent, responsive design, and trying to create a single line of database programming that will work on the web and on an iPhone lends itself to the general ideas of MVC. The web front-end technology is literally moving at the speed of light right now with Jquery, new iterations of CSS control, whereas the server side of things is moving at the pace of a snail.

Eventually, everything on the server will really just be services or "applets" that pump data to the front-end and depending on what kind of client you have, that data will be consumed and displayed differently. In that sense, MVC makes sense.

In this regard, I believe in the current real world, the MVVM is really a better "pattern" or whatever you want to call it than a controller because a controller always has to go back to the model to change the view and this is slow. In the MVVM pattern the ViewModel can give immediate updates to the view. In addition the MVVM model promotes RESTful design principals IMHO.