In most MVC frameworks, Controller class contains multiple methods, each representing one action. Then annotations and reflection is used to call those methods appropriately. But from OOP point of view, the whole class has many responsibilities, eg. one for each action. Then each action should be represented by it's own class.

Does MVC framework that implements actions like this exist? And is there some kind of discussion that discusses pros and cons of both approaches?

I believe it would be much cleaner to do it class-way, because it would allow simple extensibility through inheritance without need for annotations. But there would be 'overhead' of many more classes, making it harder to maintain the code.

  • There is one in ActionScript, RobotLegs. It uses a Command Map to allow you to "register" specific Command Classes to be executed in response to system events. I think that a lot of the inspiration came from Java ideas, so there probably is something similar in Java. May 14, 2013 at 16:03

2 Answers 2


To make it clear, what you're talking about with "expressing methods through classes" is incarnated in the Command Pattern (http://en.wikipedia.org/wiki/Command_pattern).

Many implementations of MVC pattern use the Command Pattern in order to turn the controller less monolithic. An example for an implementation in Java is avant (http://code.google.com/p/avant/).

Well, from the OOP point of view, there are quite a lot of pros:

  1. Monolithic classes (many responsibilities) violate the Seperation of Concerns principle and the associated quality maintainability
  2. By using the Command Pattern and its interface, it's easy to extend your controller by new commands
  3. If you'd like to implement something like an undo operation, you could as well do it with the command pattern easily
  4. Incarnating methods to objects lay the groundwork for decoupling, since you can pass the command objects around and invoke them at the appropriate place in your program

A small con exists though:

  • The pros don't come for nothing: you have to write a class for each and every method, that's kind of overhead and might blur the application's big picture in huge applications
  • The command pattern was a stable of the 90's. I wrote many libraries that used that pattern back then. It works great, but the disadvantage is a large set of commands are more problematic to maintain. It's better to write very fat commands.
    – Reactgular
    May 15, 2013 at 15:06

Since you are interested in "... some kind of discussion that discusses pros and cons of both approaches" here are my cons:

If you have domainlogic in your controller ( Antipattern Fat Controller )
then you can resolve this by

  • refactoring the fat controller into seperate fat actionclasses with its own domainlogic or
  • refactoring the domainlogic from the fat controller into fat models and/or fat services and create a thin controller.

Many developers prefer to have thin MVC Controllers.

If you already have a thin controller then the proposed actionclass would be to small.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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