MVC framework that uses classes instead of methods for actions

Question

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.

Answer 1

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

Answer 2

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.