When should functionality be made available in its own Controller?

Question

I am working on a web application that has to present charts on different pages. Each page corresponds to a Controller, and each Controller that needs a chart has an interface to a ChartService. The service requests a chart from a third party vendor. It then returns an image wrapped up in some HTML with JavaScript as a string directly into the output stream. The ChartService needs to be supplied with data and some other parameters like time period and template file.

Should I have the charting functionality abstracted into its own Controller? Each different type of chart could be served by a different Action Method on the ChartController.

But would it be a problem then that I'm serving some of my pages from multiple Controllers? What are the guidelines to determine when functionality should be given its own controller?

Answer 1

Sounds like you needn't change anything at all. You've abstracted away the third-party service inside of a wrapper so that your controllers don't depend directly on that specific service. Creating a new controller in this case would amount to creating a wrapper around your wrapper.

Create a new controller when you want to add behavior to the application.

Answer 2

Dave,

I'd have an abstract basecontroller that your main controller inherited from. the base controller would have all the required functionality with the child controller overriding parts that were appropriate. without knowing the full context of your dilema, this may or may not be a feasible (or desirable) approach but it's one that i employ across all of my controllers at present.

[edit] - the beauty of this approach is that if you're lucky, 75% of the basecontroller functionality will remain with only 25% of the function being overriden and/or bespoke functionality added for that child controller. this would give you a very clean paradigm as each new chart type would have it's own model/controller with potentially identical action method names, thus making the cost of 'entry' for new chart types very inexpensive.

jim

Answer 3

Each entity in your system should get its own controller.

• ChartController
• AccountController
• e.t.c

Answer 4

IMO, If you have a "charting" section with url's like

charts/income
charts/expenditure

then a charting controller makes sense. Also, if for example your charting controller is called exclusively by ajax queries from various pages, then a chartingController still makes sense. But if you're going to have urls like

products/list
products/yearlyStockChart
employees/details
employees/performanceChart

Then you'd want a ProductsController with List() and yearlyStockChart() actions, and an employeesController with details() and performanceChart() actions, with both controller making use of a chartingService.