Scott Hanselman 对 IModelBinder 的使用进行了出色的演示 “IPrincipal (User) ModelBinder in ASP.NET MVC for easier testing”他觉得有必要做出这个相当防御性的评论：
是的，我意识到我也可以为此使用 IoC 容器。
他的意思是他可以使用 IOC 而不是 IModelBinder 还是说我们应该使用 IModelBinder with IOC？了解很多很多事情可以用通用编程语言完成（现在我开始防御了）在现实世界场景中实际做了什么？例如，像KiGG 这样的项目似乎根本没有使用 IModelBinder。
【问题讨论】：
例如，在我的项目中，我有一个自定义活页夹，它可以做这样的事情（我将它与 ViewModel 一起使用，如 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);
}
}
现在，IoC 的好处是什么？为什么它是关于 IoC 的？这有助于我使我的模型绑定器不受实体解析问题的影响，同时保留关注点分离。 id 是什么意思以及我们如何获得实体被委托给解析器。这有助于为任何实体重用相同的 IModelBinder。如果（如上所示）我想按名称而不是 id 搜索，我唯一需要做的就是提供模型解析器。
这里的 IoC（我使用服务定位器，但无论如何）有助于找到合适的解析器并实例化它。请注意，解析器接受 IRepository，IoC 容器会自动传递它。
关于你的具体问题，当然我们应该使用IoC with IModelBinder，不是没有——但你或许也可以使用IoC来实例化IModelBinder——这样就可以避免使用ServiceLocator；但我不知道如何拦截创建活页夹的 MVC，坦率地说，我不在乎，因为我对 Locator 很满意。
至于 KiGG，我通常建议不要依赖示例项目，例如 NerdDinner 或 Oxite（不能告诉任何关于 KiGG 的内容），就好像它们是“好的设计”参考一样——据我所知，它们通常展示技术方面（即功能），不是好的设计。
【讨论】：
我刚刚将此添加到 codeplex http://mvcunity.codeplex.com/，这可能会有所帮助。 我还添加了一个示例应用程序，如果您有任何问题，请告诉我。
【讨论】：