MVC: my controller seems useless half of the time. Is this a problem?

Question

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.

Answer 1

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.

Answer 2

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.