Take the 2-minute tour ×


public class UserModelBinder : IModelBinder
    public UserDataService userData { get; set; }

    public object BindModel(
        ControllerContext controllerContext,
        ModelBindingContext bindingContext)
        Guid UserID =

        //userDataService = DependencyResolver.Current
        //    .GetService<UserDataService>();

        User user = userDataService.GetUser(UserID);

        return user;

noticed the commented lines of code?

I do register the binder in Global.asax as


So I can't really do injection through the construction.

UserDataService has a chain of dependencies: UserDataService -> UserRepository -> Context. So it would be good to use Ninject here.

The problem is, when I uncomment [Inject] above userData declaration, and try getting Ninject to inject object as a parameter, it does not work for some reason: I get null reference exceptions.

(could it be that UserDataService does not have an interface and I'm binding the object to itself: kernel.Bind<UserDataService>().ToSelf(); ??)

I have another commented line in the code:

userDataService = DependencyResolver.Current

When this is uncommented, the set up works, I get correct objects inserted, but now we depend on DependencyResolver and that is not much better than saying userDataService = new UserDataService()


share|improve this question
Infection you say? –  JLevett Jun 1 '12 at 10:25
@JLevett: depending on how you inject those dependencies, they might get infected :-) –  marc_s Jun 1 '12 at 10:26
+1 just for the "good laugh typo of the day" :-) –  marc_s Jun 1 '12 at 10:26
@JLevett that was not a typo, deliberate. From this article: beefycode.com/post/Dependency-Infection.aspx –  trailmax Jun 1 '12 at 10:31
@trailmax: How funny the 'Dependency infection' title might be, it doesn't help with the queryability of this subject on google. Questions on Stackoverflow are for the community, so please let your question be useful for the community and fix this 'typo' in the title. –  Steven Jun 1 '12 at 14:05
add comment

3 Answers

up vote 6 down vote accepted

A model binder should just do data conversion and should not depend on any services and certainly not trigger any database communication. That should be done in another part of your application. Your Action method should just take a Guid userId and you should call userDataService.GetUser(UserID); from within your controls (or in a lowel layer, for instance, inside a business command). By doing this, your problem will not exist.

share|improve this answer
Yeah, I had that in the first place, but then I had userData.GetUser(UserID) all over controllers, in every call. Also controllers were confused with two Guid objects being passed in: Delete(Guid ID, Guid UserID) and instead of object ID, controller was given two UserID. Unless there is a way to solve this problem... –  trailmax Jun 1 '12 at 13:05
@trailmax: Then there is probably something wrong with your routing. And if not, move create a new question here at SO. Nontheless, you are fixing this problem in the wrong way. –  Steven Jun 1 '12 at 13:18
yep, I got your point. Probably will go your route. Thanks! –  trailmax Jun 1 '12 at 13:33
Model binders create type instances and the sub-type created might depend on the type of the item you're binding. So if you only have a key then you need to look up the type which might be in a database! –  Ian Warburton Jan 21 at 13:49
add comment

You could do this:

public class UserModelBinder : IModelBinder
    public Func<UserDataService> UserData { get; set; }

    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
        Guid UserID = (Guid)Membership.GetUser().ProviderUserKey;

        User u = UserData().GetUser(UserID);

        return u;

Then when you wire it up:

ModelBinders.Binders[typeof(User)] = new UserModelBinder() 
    userData = () => DependencyResolver.Current.GetService<UserDataService>();

The benefit is that your UserModelBinder isn't aware that a container is being used, while still being open for injection.

But I agree with Steven - using a model binder for this doesn't seem quite right. Instead you might inject an ICurrentUserContext into your controllers, where the implementation returns the current user. Then you don't even need to add a parameter to your controller actions.

share|improve this answer
add comment

Use the DependencyResolver.Current to get your service. This is actually much better than using new, because it means you have not coupled getting that service to the type of the service. You can decide later to make UserDataService an abstraction and plug in different variants without changing your client code, which is really the whole point.

Also, DependencyResolver.Current is a settable IDependencyResolver, so you could implement that interface yourself, with a class that backs it with Ninject if you like that framework.

Another way to do dependency injection in MVC3 is to setup your own IControllerActivator, which allows you to do constructor injection instead, if you like.

share|improve this answer
Yeah, I understand what DependencyResolver does and why it is better than creating via "new". Should any class be ignorant of DI going on at all? Hence the title "infection". –  trailmax Jun 1 '12 at 12:35
You mean should most of your classes be ignorant of your DI framework? Absolutely, almost all of them should be ignorant of it! It should be encapsulated too. See this great article from Uncle Bob on the topic: blog.objectmentor.com/articles/2010/01/17/… –  tallseth Jun 1 '12 at 12:38
add comment

Your Answer


