在ASP.NET MVC中是IModelBinder还是IOC?

例如,在我的项目中,我有一个这样做的自定义绑定器(我将它与视图模型一起使用,如图所示 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);
   }
}

现在,国际奥委会的好处是什么?为什么会这样?这有助于我保持模型绑定器不受实体解析关注,保持关注分离。ID意味着什么以及我们如何获得实体被委托给解析器。这有助于为任何实体重用相同的IModelBinder。我唯一需要做的就是提供模型解析器,如果(如上所示),我想按名称而不是按ID进行搜索。

这里的ioc(我使用服务定位器,但无论如何)帮助找到合适的解析器并实例化它。请注意,解析器接受IRepository,IOC容器会自动传递它。

关于你的具体问题,我们当然应该使用国际奥委会 具有 imodelbinder,不是没有,但你也可以使用ioc来实例化imodelbinder,这将避免使用servicelocator的需要;但是我不知道如何拦截创建绑定器的MVC,坦率地说,我不在乎,因为我对locator很满意。

至于kigg,我通常建议不要依赖像nerddinner或oxite这样的示例项目(不能告诉任何关于kigg的信息),就像它们是“好的设计”参考一样-据我所见,它们通常展示技术方面(即功能),而不是好的设计。

我刚把这个添加到codeplex http://mvcunity.codeplex.com/ 可能会有帮助。 我还添加了一个示例应用程序,如果您有任何问题,请告诉我。