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.

Often when I design a program with MVC, the controller is useless half of the time.

What I mean is this: something happens on the view (e.g. a button click). The view then notifies the controller. The controller then directly delegates to the model and does nothing else because it has nothing to do.

For example:

User presses button 'Color Blue' > view tells controller controller.colorBlue() > controller tells model model.colorBlue() > model colors something blue.

In this example, the controller seems useless. It adds nothing. The view might as well have talked straight to the model.

The other half of the time, however, the controller does do some kind of mediation between the view and model.

My question is this: how common is this in MVC structures? Is it reasonable that half the time my controller seems unnecessary? Or is this a problem? Is this common? How should I approach this?

If my question isn't clear enough, please say so.

share|improve this question
1  
as hinted by RobertHarvey though, for this particular example, it might be better if controller.colorBlue() actually then calls model.setColor(0, 0, 255);. One reason for separation between Model and View is that it is often the case that you have multiple UI elements to represent a single state in the model (e.g. an item is checked in the menu, the toolbar is depressed, and pointer changes to a fill icon all corresponds to the currently selected tool field in the model), with MVC separation the model would not have to worry about synchronizing the different UI elements. –  Lie Ryan May 7 at 22:07

2 Answers 2

up vote 11 down vote accepted

You're underestimating the importance of having a layer of abstraction between your User Interface and your Model. The Controller fulfills this function 100 percent of the time.

Your example model.colorBlue() is a bit specious. In a real model, this would probably be a CRUD method. So your button might be a Create Customer button, your controller method would be CreateCustomer() and your Model would be CreateCustomer(). Sure, you're just passing through the call.

But what if you needed to change the way the model works? If your View were calling your model directly, your application will break if you change the Model. Controller methods provide an "access point" for your View; you can make a simple modification to the controller method, perhaps by changing the Model call to CreateCustomerWithVerification(), and everything still works.

The same reasoning applies for having a Service Layer. Instead of simply having CRUD methods in your model, you should have business actions. That way, you keep business logic out of your controllers, and make it possible to use the Model somewhere else, perhaps in a WPF application.

Think of the Controller as a "Switchyard." It should be a go-between, mediating requests between your UI and your Model, but controller methods should have as little logic in them as possible.

share|improve this answer
    
Let me see if I get what you're saying. You're saying that even if the controller simply delegates straight to the model, it's still good to have one between the view and model becasue of this: if the model changes, all the objects calling it's methods might have to change. If the view is the one that calls methods on the model, it'll have to change. If the controller calls the methods, it'll also have to change. But the difference is that the view is responsible to display the UI - an important piece of the app. The controller's only responsibility, however, is exactly this - communicate [..] –  Prog May 7 at 21:34
    
with the model. And because of this, it's better to change the controller when the model changes (and leave the view the same), then change the view. –  Prog May 7 at 21:35
3  
Yes, that's exactly right. The separation provided by the Controller layer allows changes in the Model without breaking the UI or the routing. –  Robert Harvey May 7 at 21:35
    
I see. And just to be sure: it's better to change the controller than the view when the model changes, because the view is responsible for important logic - displaying the UI. Changing it theoretically puts all it's other code at risk. However the controller's only purpose is exactly this, communicate stuff to the model, and thus depend on the model - so the view doesn't have to. And because the controller does not include any other important logic, it's better that the controller changes when the model does, than the view having to change. Is this accurate? –  Prog May 7 at 21:38
1  
+1 for teaching me the word "specious". –  Erik Madsen May 8 at 8:25

While coding you could think this way:

  • Will I be able to change view to something else (console, service) or you same controller for different view?
  • Will I be able to change model to handle different database or write to some external service?

In your case it seems you are putting domain logic into model and that would cause you problems if you want to change it: you will have to copy methods like "model.colorBlue" to new model.

And what would happen if definition of "blue" changes? You will have to change it 2 models. Also in controller you should not write directly into your database, but as Lie Ryan pointed you should use model.setColor.

Same with views. If you start putting logic or validation into view then if you want to change view you will have to copy all that functionality.

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.