为什么IDependencyResolver与.NET框架中的System.Web程序集（Mvc或Http）相关联的原因是什么？
DI系统的目标不是它应该提供一种向客户提供依赖关系的不可知方式吗？如果我想在项目中使用IDependencyResolver而不应该引用与System.Web相关的任何内容，该怎么办？
修改
这是一个哲学问题，而不是关于如何做的请求，因为我知道还有其他选择，比如开源DI库。
答案 0 :(得分：6)
DI系统的目标不是它应该提供一种向客户提供依赖关系的不可知方式吗？
这是正确的，但在这种情况下，IDependencyResolver特定于定义它的库。正是该库的DI抽象允许依赖解析的不可知的扩展点。而且我相信这是抽象的最初目标。
其他图书馆并没有真正重复使用它，这很明显，MVC和Web API都有两个版本。虽然它们具有相同的名称并具有相同的目的，但它们的实现略有不同。
它还演示了Mark Seemann在本文中提到的Conforming Container反模式，其中文章还提到了上述抽象作为.NET的Conforming Containers的已知示例。甚至我使用IServiceProvider的首选方法都是列表。
如果我想在项目中使用
IDependencyResolver该怎么办？ 不引用与System.Web相关的任何内容？
我的建议是不要使用 System.Web 中的IDependencyResolver。我还要补充一点，首先应特别注意遵循适当的设计模式，确保人们对概念有所了解，应该在哪些方面应用或避免使用。
答案 1 :(得分：2)
接口$images = Image::with('galleries')
->whereHas('galleries', function ($query) use ($search) {
$query->where('slug', $search);
})
->paginate();
是System.Web-frameworks的扩展点。框架依赖于此接口来解析（控制器及其类似物）及其依赖项的实例。
框架有自己的接口实现，但您可以提供自己的接口实现。内置实现具有有限的功能（外部配置，注入类型，拦截）。</ p>
大多数IOC-Container和DI-Frameworks提供此接口的实现，以便您可以将它们集成到现有框架中。
答案 2 :(得分：2)
为什么IDependencyResolver与之相关的原因 .NET框架中的System.Web程序集（Mvc或Http）？
因为它是用于解析框架服务的接口。但是是的......他们至少应该使用IServiceProvider命名空间中的System。
DI系统的目标并不是它应该提供一种不可知的方式 为客户提供依赖？
不。这不是那种背景下的目标。框架作者的主要目标是让您扩展甚至替换正在使用的内部服务框架。
在您的代码中，您应该在这些“标准”界面上引入自己的外观。它们是非常弱的抽象 - 有利于基础，但远离任何更丰富的解决或终身管理策略。
如果我想在不应该使用的项目中使用IDependencyResolver，该怎么办？ 引用与System.Web相关的任何内容？
你不能（没有添加System.Web引用），你不应该。在DI框架上使用您自己的内部抽象（Facade）。就像你不应该在你的类中直接使用NLog.ILogger一样，同样适用于DI框架抽象。
有些框架会让它接近或完全不可能，但你应尽可能使用自己的外观。
同样的规则也适用于更广泛的意义。 不要将您的项目（不必要地）附加到某些云服务（如Azure）。另一方可能有一天会有更好的价格。尽可能限制依赖关系和粘性部分。
编辑： 这是一个哲学问题，而不是关于如何做的请求， 因为我知道还有其他替代方案，比如开源DI库。
哦......和DI框架一样的建议。不要过度使用DI框架功能，这些功能可以通过Facade以不同的方式轻松实现。
注意：同样适用：CI管道，服务总线/消息队列框架。