我对 DI 和 IoC 有点困惑。我已经设置了 MVC，并使用 Ninject 进行属性注入，它运行良好。我的应用程序设置为使用 MvcContrib 的 Portable Areas，每个区域都包含在提供程序、服务、模型和控制器中。
一个区域的提供者可以访问同一或子程序集中的其他提供者。为了解决提供者中的依赖关系，我使用了 DependencyResolver.Cur... ，它也被注册为使用 Ninject。我想知道这是否是一种好方法，因为我不想将所有其他提供程序从控制器传递到最后一层，但我想直接从提供程序访问它们。我应该在像 Core 这样的最低程序集中创建一个内核实例，以便我可以从任何地方直接访问它吗？
提前谢谢
更新：我还想知道是否可以在普通类中使用属性注入。
当您围绕构造函数注入模式设计所有服务（存储库、应用程序服务、控制器等）时，无需从类中调用DependencyResolver.Current.GetService，也无需在最低程序集中提供内核实例。
当您的所有服务都使用构造函数注入时，您的容器将能够在请求根类型时构造依赖服务的对象图：在您的情况下是控制器类。当你这样做时，没有代码需要直接访问DependencyResolver或Kernel，这确保你的代码将更加可测试、灵活和可维护。任何访问DependencyResolver静态Kernel实例的代码都很难测试，隐藏了它的依赖关系，并且很难以自动化的方式验证容器的配置。
您可以使用属性注入来实现相同的效果，而不是使用构造函数注入。但是，由于约定是属性用于可选依赖项，因此 Ninject（和任何其他容器）将跳过它无法注入的属性（隐式属性注入），而不是抛出异常，就像缺少构造函数参数依赖项那样. 这再次使得在您的应用程序中查找配置错误变得更加困难。所以，只要有可能，坚持使用构造函数注入。