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.

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.

share|improve this question
    
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. –  Amy Blankenship May 14 '13 at 16:03
add comment

2 Answers

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
share|improve this answer
    
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. –  Mathew Foscarini May 15 '13 at 15:06
add comment

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.

share|improve this answer
add comment

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.