Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a nice MVC set up going but my website requires some views that don't map directly to a model. Specifically I've got some generic Reports users need to run, and now I'm creating a utility for comparing some system configurations.

Right now the logic is crammed into a Reports Controller and I'm starting a Comparison Controller but this feels like a big abuse of the system. Both controllers use an assortment of different Models to pull data from, and they're only related based on what the user is doing. Reports are run from the Reports Controller and their views are all grouped together in the file system/URL structure.

Is this an acceptable use of the Controller paradigm? I can't think of a better way to structure my Controllers, and making a Controller for each model I'm using to make reports/ect doesn't seem like a good idea; I'd end up with one Controller/Model/View per report or comparison, vastly complicating the apparent structure of my site.

share|improve this question
@RobertHarvey why fat models over controllers? Our last programmer largely abused Models and we've got a lot of icky code in them, I've been trying to minimize logic in Models. – Ben Brocka Apr 12 '12 at 19:49
Then add a Business Layer, between the model and the controllers, that is responsible for business logic (including your Comparison aspects). – Robert Harvey Apr 12 '12 at 19:55
I'm confused. The M and the C aren't typically my concern but since when are models and controllers supposed to be a 1 to 1 thing? If they were 1 to 1, why separate them in the first place? – Erik Reppen Apr 13 '12 at 3:30
up vote 7 down vote accepted

Favor thin controllers; push as much of the data analysis as you can into a Business Logic Layer that coordinates data transfer between the controllers and the model, and use the controllers merely to coordinate the display of the data.

The model is not necessarily a database. In MVC, the Model is both the data and the business logic needed to manipulate the data in the application.

share|improve this answer

Your Answer


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.