Interface arguments in ASP.NET MVC

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

I definitely agree that this goes far beyond the scope of the typical IoC usage pattern. In terms of testing, I still expect to see mocked interfaces, as opposed to constructing data objects, which has the potential of introducing new variables into my testing scenario, but I suppose that might just be another argument for keeping the data objects as containers for data and nothing more.

ph0enix 2010-07-06 21:50:54

@ph0enix Your view models may have some logic for composing output for a view, but your action parameters should basically be data containers without interfaces. Besides, interfaces make the model binding more difficult than it needs to be. How would the model binder know which implementation to use? I would recommend striving for one view model and one parameter model for each action: SRP.

Ryan 2010-07-07 00:55:56

"In terms of testing, I still expect to see mocked interfaces" For view models? Why?

jfar 2010-07-07 03:37:08

@Ryan In our code, we've taken this approach and each model implements a common interface to enforce the naming conventions on the form collection, as expected by the model binder. The alternative seems to be properties on each mode that magically work because the names match up, but there's no way to enforce it. Does this seem like a valid approach?

ph0enix 2010-07-07 04:08:53

@jfar Coming from the world of WPF, I'm used to view models that are more than just simple data containers, and it's much easier to achieve the expected results using mocked objects rather than hard references.

ph0enix 2010-07-07 04:17:17

@ph0enix WPF uses a totally different presentation pattern. This is getting to be one of those "I want people to agree with me questions" not "I want people's opinion".

jfar 2010-07-07 13:11:22

@jfar "This is getting to be one of those 'I want people to agree with me questions' not 'I want people's opinion'" To be fair, other than asking the original question, I don't think I've really pushed my own point of view at all, nor have I really disagreed with anything you've brought up.

ph0enix 2010-07-07 14:00:10

ansaurus

tags:

views:

answers:

Interface arguments in ASP.NET MVC

related questions