I have a controller which contains a few private read only interface properties which it needs in order to get data by calling a service which is then used to populate models etc
private readonly ISomeInterface _someObject;
Which gets set in the Controllers constructor:
public ... (ISomeInterface someInterface, ...) {
...
_someObject = someObject
}
_someObject is then used in a call to the service layer to get data.
I had to add another property to the controller but now when I build the soloution I get the following error:
CA1506 : Microsoft.Maintainability : 'ControllerName' is coupled with 87 different types from 30 different namespaces. Rewrite or refactor this class's methods to decrease its class coupling, or consider moving some of the class's methods to some of the other types it is tightly coupled with.
It asks me to reduce the coupling of the class, I understand that one way of doing this is to code against interfaces (abstractions) – which I’m already doing by adding the interface property? It seems by adding one more property it takes it past the threshold for flagging up this error.
If I remove it, I can’t get the data I need? What do I need to modify?
How many actions does your controller have? Do you have a view model for each action? Do you have an input model for each action? Are you interacting with different classes for each controller action? You may need to split your controller up into multiple controllers to make it do less giving it fewer reasons to change and also fewer dependencies. Although using an interface would decouple the controller from the specific implementation of ISomeInterface it doesn’t do anything in terms of that warning. Changing to using the Interface didn’t reduce the number of types… it just changed from concrete type to an interface type.
The problem is warning against having one class that does many many things. Having many dependencies suggests the class is doing too much and should be divided up. For example if this controller has say an action for “Bake Pie” and “Eat Pie” and “Make Ice Cream” and “Deliver food” you could move “deliver food” to a brand new class… you could break out the Make Ice Cream as well and then you would evaluate if Bake Pie and Eat Pie should stay together in the same class or be put in separate classes. The pies debate opens a can of worms which folks would debate.
see: SOLID (object-oriented design)
Do you have code that has to call 2 or more different data access classes that then calls another class to to create a view model. You could move that whole operation to a new class thus reducing your dependency on 3 classes down to 1.