IModelBinder还是ASP.NET MVC中的IOC？

Question

虽然Scott很好地展示了IModelBinder在“IPrincipal (用户) ModelBinder在ASP.NET MVC中用于更容易的测试”中的使用，但他感到不得不做出这样一个相当保守的评论：

是的，我知道我也需要一个IoC容器。

他是说他可以使用国际奥委会而不是IModelBinder，还是说我们应该在国际奥委会中使用IModelBinder？有了这样的理解，很多事情都可以用通用的编程语言来完成(现在我开始防御性了)--在现实世界的场景中，实际上是怎么做的呢？例如，像KiGG这样的项目似乎根本没有使用IModelBinder。

Answer 1

例如，在我的项目中，我有一个定制的绑定器来执行类似的操作(我将它与ViewModel一起使用，如所示的这里)：

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的？这帮助我保持我的模型活页夹没有实体解析关注点，保持关注点的分离。id意味着什么以及我们如何获得实体被委托给解析器。这有助于对任何实体重用相同的IModelBinder。我唯一需要做的就是提供模型解析器，如果(如上面所示)我想按名称而不是id进行搜索。

这里的IoC (我使用Service，但无论如何)有助于找到合适的解析器并实例化它。注意，解析器接受IRepository，IoC容器会自动传递它。

关于您的具体问题，我们当然应该使用IoC 和 IModelBinder，但您可能也可以使用IoC实例化IModelBinder --这将避免使用ServiceLocator；但我不知道如何拦截MVC创建绑定器，坦率地说，我不在乎，因为我对Locator很满意。

至于KiGG，我通常建议不要依赖像NerdDinner或Oxite这样的示例项目(不能告诉任何关于KiGG的信息)，就我所见，它们是“良好的设计”参考--就我所见，它们通常展示技术方面(即特性)，而不是好的设计。

Answer 2

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