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.
How do I handle a Controller that's not controlling a specific Model?
mvc
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.