I’m in the process of developing an ASP.NET MVC project, and after several weeks of research, I have a pretty good framework in place using StructureMap to register my dependencies at bootstrap time, create my controllers with the correct implementations, a custom model binder for passing data to my controller, etc.
After thinking about the data objects being passed to my controller actions, I began to wonder… should controller actions take in interfaces or concrete types?
It makes perfect sense that when my controller is being constructed by the controller factory, the dependencies should be passed into my constructor as interfaces, but what about the data objects created by the model binder? Should they be registered into my IoC container as well?
In code, it’s only a few extra lines to hook it all up so the engineering overhead is pretty low. On the other hand, based on the nature of the framework, I’m not going to need to handle different implementations in the final product. But with everything I’ve learned about “future-proofing” my code, interface-driven design, designing for testability, loose coupling, and any other buzz words you can think of on this topic, my gut still tells me that interfaces should be the way to go.
I hope I’ve made some sense in my dilemma. Does anyone have any strong opinions one way or another on this topic?
TIA, -J
No way. You wouldn’t be solving the problem IoC is meant to solve.
Viewmodels should be dumb as dirt. IoC is good for swapping implementation details. Since your view models are dumb what kind of implementation details can you possible swap? View Models also have narrow and non-orthogonal responsibilities very unlike traditional injectable classes like ILogger or IRepository.
IMHO this would be some serious over-engineering and the resulting complexity ( I’d anticipate service location responsibilities in your controllers for edit scenarios ) wouldn’t be worth it.