Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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")

share|improve this question
6  
MVC is simply a implementation of Seperation of Concerns. Any implementation will do. Not using Seperations of Concerns tends to lead towards a Big ball of mud –  Raynos Sep 1 '11 at 23:43
    
@Raynos: Perhaps. But that's not where the "hype" is going. –  Billy ONeal Sep 1 '11 at 23:44
    
hype obeys the hype curve. Don't let it influence you too much. From my point of view, MVC is a solid architecture for SoC and easy to implement. I can't think of a solid alternative. –  Raynos Sep 1 '11 at 23:49
    
most existing user-interface frameworks tightly link V and C and when you switch to another you'll need to rewrite both the view and controller (the interface from M to the what the user sees) –  ratchet freak Sep 2 '11 at 1:16
    
But Separation of Concerns is a property of OO development. You don't have to use a MVW pattern to implement a correct Separation of Concerns code? –  B413 Apr 16 at 18:07

6 Answers 6

up vote 22 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
1  
"in projects where the actions you carry out do not apply directly to changes in the model" What do you mean by "model" here? The database? Because everyone I've talked to says that such actions still belong in a model, not in controllers. (e.g. that controllers should only be dealing with HTTP stuff...) –  Billy ONeal Sep 1 '11 at 19:10
    
What counts as HTTP stuff? I would include the following in a controller: Unmarshalling HTTP request parameters, checking the parameters for basic sanity, determining what needs to be done, visiting appropriate model objects (to read, write or both), producing a final result based upon the model's responses, passing that off to the view. A silly example of something only a controller would be used for might be a web service generating a random number - in this case there is no 'model' to look at (in my mind at least...) –  Unk Sep 1 '11 at 19:26
    
Those are all model concerns. Even "deciding what needs to be done" (the "front controller") is a model. –  Billy ONeal Sep 1 '11 at 22:07
    
My feeling (possibly unusual) is that we shouldn't just lump all 'domain logic' under a single 'model' concept. Domain logic can contain behaviours as well as entities - not always intrinsically linked. In a larger system carrying out complex actions, I'd say there's always easily more than 3 layers. e.g. Raw storage -> entities -> behaviour -> mapping of requests/responses to behaviour inputs/outputs -> presentation. As long as your behaviour is completely separated from both your underlying data storage and your presentation layer, I'm happy. –  Unk Sep 1 '11 at 22:40
1  
Not to mention controllers are useful for not hard-coupling your models to your views. As well as allowing you to connect many views to many models through one controller. –  Raynos Sep 1 '11 at 23:53

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)

share|improve this answer
    
I totally agree, good answer. The controller isn't always necessary, it's just meant as a strategy for the view to communicate with the model. –  Falcon Sep 1 '11 at 19:17
    
@Falcon: See, that's my confusion. I've seen more than one person say that the view shouldn't talk with the controller at all; that it should talk only to the model... –  Billy ONeal Sep 1 '11 at 23:43
1  
If you're using an actual MVC implementation, the view doesn't talk to the controller (or the model for that matter). The controller sets the model's state, prepares the data for the view and pushes it to the view. –  Demian Brecht Sep 1 '11 at 23:44
    
@Demian: I've heard the reverse (that controllers should do effectively nothing). Often. That's my biggest problem with this pattern; nobody seems to agree on what it is. –  Billy ONeal Sep 2 '11 at 15:07
1  
Yep, I've often heard that if you get 10 programmers in a room, you'll get 9 different definition of what MVC is. Really, the main point is the separation of concerns. What else goes on seems to be a religious debate. –  Demian Brecht Sep 2 '11 at 15:14

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.

share|improve this answer
    
That's no different than simply defining a UI layer and a functional layer. You haven't explained why the controller bit is necessary. –  Billy ONeal Sep 1 '11 at 22:07

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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