For example, in my project I have a custom binder that does something like this (I use it with ViewModel like shown here):
public interface IEntityResolver
{
object Find(string id);
}
public class PrimaryKeyResolver<T> where T: Entity
{
public PrimaryKeyResolver(IRepository<T> repository) {}
public object Find(string id)
{
return repository.Get(new Guid(id));
}
}
public class NameResolver<T> where T: NamedEntity
{
public NameResolver(IRepository<T> repository) {}
public object Find(string id)
{
return repository.Find(new { Name = id });
}
}
public class MyBinder: IModelBinder
{
public override object BindModel()
{
var id = ... //get id from context
var resolverType = typeof(IResolver<>).MakeGenericInterface(typeof(bindingContext.ModelType));
var resolver = ServiceLocator.Current.GetInstance(resolverType);
return resolver.Find(id);
}
}
Now, what are the benefits and why it's about IoC? This helps me to keep my model binder free of entity resolution concerns, preserving Separation of Concerns. What does id means and how we get entity is delegated to resolver. This helps to reuse same IModelBinder for any entity. The only thing I need to do is to provide model resolver if (as shown above) I want to search by name, not by id.
IoC here (I use Service Locator but anyway) helps to find proper resolver and instantiate it. Notice that resolvers accept IRepository, which IoC container passes automatically.
About your specific questions, of course we should use IoC with IModelBinder, not without - but you can probably also use IoC to instantiate IModelBinder - this will avoid the need to use ServiceLocator; but I don't know how to intercept MVC creating the binder, and frankly I don't care since I'm happy with Locator.
As for KiGG, I usually suggest not to rely on example projects such as NerdDinner or Oxite (can't tell anything about KiGG) as if they're "good design" references - as far as I see they usually demonstrate technical aspects (i.e. features), not good design.