I am current working on a semi large MVC 2 project and the number of controllers we have with associated views and viewmodels is becoming quite large. In order to try and provide a bit of separation I have been looking into using the areas feature of MVC 2 and refactoring the project accordingly.
One of the issues I face is we have an inheritance hierachy for our controllers in order to share functionality and properties that we use in concrete controllers that then expose the necessary actions we wish to deal with.
Essentially we currently have a setup like so in our main controllers folder:
Controller (MVC)
+-- BaseController (Abstract)
+-- BaseWorkController (Abstract)
+-- BaseWorkAController (Abstract)
+-- ... a number of controllers exposing actions
+-- BaseWorkBControllers (Abstract)
+-- ... a number of controllers exposing actions
I am thinking of creating Areas for each work controller i.e.
- Area/WorkA
- Area/WorkB
Each area would have their associated views and viewmodels and even models.
However the problem I seem to face is where do I place the BaseWorkController. Is it ok to leave that in the main Controllers folder and the area controllers just include a reference to that controller. Also code in the different areas might need access to different models and even some attributes that we create for certain functionality.
Does this setup seem like an acceptable use of areas. From what I have read areas seem to help with seperating concerns and functionality which is what I’m looking for. However I don’t want to invest in doing this if it is a complete wrong use of the functionality?
Is it acceptable that controller code use functionality from other areas or the main core controller/model/view folders.
The amount of Inheritance in you application is a warning to me. If you have that much shared behavior, I think you should consider pulling it out of the controller itself and create some classes that encapsulate the shared logic, and then you can extend the functionality of your controllers via composition, rather than inheritance.
To answer your question, there are no issues with sharing logic from a base controller into controllers in other areas. If it makes sense to do so. But if you start getting several layers deep in your inheritance chain, I would strongly consider reviewing the code and seeing if the shared logic might make sense in a different shared class, than complicating things with multiple overrides.
You might want to look into the strategy pattern if you are overriding behavior at different levels. You can use that pattern to swap behavior of components and use composition, rather than inheritance.