何时想通过IModelBinder使用IDependencyResolver？

Question

创建新项目时，将表单信息从表单发回控制器时，它表示不能找到无参数的构造函数。这是预期的，因为用作视图模型的视图模型取决于域模型对象。

然后我决定写我自己的模型活页夹。

NewItemViewModelBinder

public class NewItemViewModelBinder : DefaultModelBinder { 
    public NewItemViewModelBinder(IKernel kernel) { 
     if (kernel == null) throw new ArgumentNullException("kernel"); 
     this.kernel = kernel; 
    } 

    protected override object CreateModel(ControllerContext controllerContext 
     , ModelBindingContext bindingContext, Type modelType) { 
     return kernel.Get(modelType); 
    } 

    private readonly IKernel kernel; 
} 

这与模型粘合剂溶液的工作只是罚款有已经登记该粘合剂的NinjectWebCommon.RegisterServices方法中的ModelBinders.Binders。

public void RegisterServices(IKernel kernel) { 
    CompositionRoot.ComposeObjectGraph(); 
    ModelBinders 
     .Binders 
     .Add(typeof(NewItemViewModel), new NewItemViewModelBinder(kernel)); 
} 

此外，我还遇到一些其他职位，谈论有关DependencyResolver。所以我认为如果我可以编写一个可以解决所有其他创建问题的依赖解析器，那么我就可以为其余的解决问题了。

NinjectDependencyResolver

public class NinjectDependencyResolver : NinjectDependencyScope 
    : System.Web.Http.Dependencies.IDependencyResolver 
    , System.Web.Mvc.IDependencyResolver { 
    public NinjectDepencyResolver(IKernel kernel 
     , IDependencyScopeFactory factory) : base(kernel) { 
     if (kernel == null) throw new ArgumentNullException("kernel"); 
     if (factory == null) throw new ArgumentNullException("factory"); 
     this.kernel = kernel; 
    } 

    public IDependencyScope BeginScope() { 
     return factory.Create(kernel.BeginBlock()); 
    } 

    public object GetService(Type serviceType) { 
     return kernel.TryGet(serviceType); 
    } 

    public IEnumerable<object> GetServices(Type serviceType) { 
     return kernel.GetAll(serviceType); 
    } 

    public void Dispose() { base.Dispose(); } 

    private readonly IKernel kernel; 
    private readonly IDependencyScopeFactory factory; 
} 

和设置这一新的解析器的依赖解析器的MVC后，

DependencyResolver.SetResolver(new NinjectDependencyResolver(kernel)); 

它没有工作，我有同样的问题作为参数 - 更少的构造函数。

所以，我有三个问题。

1. 我对DependencyResolver方法做了什么错误？
2. 使用DependencyResolver和ModelBinder有什么好处？
3. 何时使用其中之一？

Answer 1

根据Wrox Professional ASP.NET MVC 4，第308页，您不应将IDependencyResolver用于您的应用程序。

您应该在您的 应用程序中使用依赖性RESERVE吗？ 您可能想要从您自己的 应用程序中使用IDependencyResolver。抵制那种诱惑。 依赖关系解析器接口正是MVC需要的 - 而且更多的东西都不是 。它不打算隐藏或替换您的依赖关系 注射容器的传统API。大多数容器都有复杂而有趣的API;实际上，它可能是 ，您可能会根据其提供的API和功能比其他任何原因更多地选择您的容器。

的IDependencyResolver旨在供应依赖于MVC框架，而不是你的应用程序。

IDependencyResolver的实现方式遵循service locator (anti-)pattern。

此外，IDependencyResolver不需要使用DI与MVC。更好的选择是使用IControllerFactory将依赖关系注入控制器，并使用其他扩展点（如IModelBinder），使用构造函数注入而不是服务位置。因为你正在做构造函数注入（虽然有些人可能会争辩说模型不应该有依赖关系，但这取决于你的框架设计）。至于使用IModelBinder，你正在使用一个好的做法。

作为开发人员，我们总是倾向于尝试尽可能地推广设计，毕竟这通常是最佳的行动方案。但是，谈到DI时，我们必须与这种冲动作斗争。对于DI，最好让每个类明确地按类型请求它自己的依赖关系，这样就很明显类需要什么功能。服务定位器处于这个范围的另一端 - 这是一个黑盒子的服务，它可能包含或不包含应用程序运行所需的所有类型，并且使应用程序配置更加困难。