Should I inject a mapping class in an ASP.NET MVC controller

Question

I have a discussion with a colleague.

He thinks we should inject a mapping class (for mapping the domainmodel to a viewmodel) in a controller. He thinks we now can test the mapping class (which is an automapper class for some properties) and we can inject another implementation when we need it.

My opinion is that the logic for this kind of mapping will not be changed with another implementation nor does it need to be tested separately, because it is not reused.

He also thinks it is more 'elegant' and it's better because it's decoupled.

I think you should not decouple your code when it's only used in one place. In my opinion it is not bad to have code which is tied to one class only, in that class, and that there is a such thing as 'over-decoupling'.

I would appreciate your opinion on this.

Answer 1

No, you don't need dependency injection for this. MVC is already adequately decoupled, and you've decoupled it further by using a ViewModel and Automapper.

If you need to change the implementation, then just change it in the ViewModel or in Automapper. If you need to share a ViewModel with different domains, provide an additional method on the ViewModel that returns a different object, or adjust AutoMapper accordingly.

The purpose of dependency injection is to inject an implementation of some behavior, and that's not what this is about. It's merely scaffolding; adding dependency injection would simply increase the complexity for no discernible benefit.