views:

60

answers:

3

Hi,

i have several controllers which will all be using common functionality. So i have separated that functionality into a separate controller.

the shared controller needs a parameter specific to which controller it is being used from, and needs to return views based on id ints passed to it.

So, one idea is to create an instance of SharedController(int callingControllerId) in the constructor of each of the controllers that will be using it. Then, within the action methods of each controller, call the action methods of the shared controller, passing appropriate ids, and returning views from SharedController to the calling controller, which would return the view to be rendered.

Does this sound right? Should controllers be creating other controllers in MVC?

Thanks!

+2  A: 

Absolutely not although having your controller inherit from a shared, base controller is pretty common.

public KittyController : MySharedBaseController
{

}

Like Greg Roberts points out that although having a ControllerBase is common it is not always the best place to store shared functionality. MVC has a lot of extensibility points and picking a narrow place to wedge in your code is a lot better than smushing tons of things into a base controller.

jfar
I would agree this is common to have a base controller, but not common to have one that knows about its inheritors.
Greg Roberts
+2  A: 

I would agree that a base controller is pretty common, but I'm not sure it's the right solution for what you are describing.

Without knowing what is exactly shared it's a bit hard to figure out, but the whole bit of your base controller knowing specifics about the controllers that are inheriting from it smells a bit.

Here are a couple things to consider.

  • Composition is almost always better than inheritance. Great article on this
  • Base controller should have common methods/properties, for example mine have some properties of getting the current user and a generic method for calling external services, but not specific things from inheriting controllers. Rule of thumb, if it's not needed by more than 1 controller, than probably not good in base implementation.
  • It's possible that some of the new MVC 2 features might solve what you are doing. Look at render action.

As with anything in software, there are tons of ways to solve the problem, so ultimately do it the way that makes the most sense to you and your team.

Greg Roberts
+1  A: 

Controllers are constructed by the ASP.NET MVC runtime and you should never be constructing them in your own code. It sounds like you don't really need a separate controller, you just need another class that you aggregate in the controller, and use as a service. This is perfectly acceptable. In fact, I would go so far as to say that in general controller should be delegating their work to other "service" classes and shouldn't have much responsibility (especially domain logic) in and of themselves.

I don't know the details of why this service class needs to know what controller it is being called from, but perhaps you can just declare an enum that defines the different use cases, and pass that in in its constructor. Actually having the service class know about different controllers would be a code smell for me.

jkohlhepp