ASP.NET WebForms与非Core版ASP.NET MVC5默认DI容器相关问询

针对这类传统ASP.NET应用是否内置默认DI容器的疑问，结合框架实际实现给出明确结论：

1. ASP.NET WebForms 是否存在默认DI容器 #

• 所有基于.NET Framework 的ASP.NET WebForms 版本，不存在面向开发者提供的通用内置DI容器
• 框架内部对页面、服务器控件的实例化属于硬编码的内部实现，不对外暴露服务注册、依赖解析的扩展点，不支持构造函数注入、生命周期管理等通用DI核心能力，本质上不属于可被项目复用的DI容器范畴。如果要在WebForms项目中使用依赖注入，必须自行引入第三方DI组件，额外适配WebForms的页面生命周期完成注入逻辑。

2. 非ASP.NET Core的ASP.NET MVC5 是否存在默认DI容器 #

• 基于.NET Framework 构建的ASP.NET MVC5，不存在独立的、可通用的内置DI容器，仅在Controller实例化流程中存在一套极度简化的内置对象解析逻辑。
• 这套逻辑内嵌在默认的Controller工厂实现中，仅能自动实例化拥有无参公共构造函数的依赖对象，不支持接口、抽象类的依赖映射，也不具备完整的服务注册、生命周期管理、全链路依赖递归解析能力，和大家认知中可投入项目使用的DI容器有本质区别。

3. 内置实现的名称与项目适用性 #

• 上述MVC5内置的解析逻辑并非独立DI容器，没有单独的容器命名，它是DefaultControllerFactory类的内嵌逻辑，不对外暴露独立的服务注册入口。
• 该内置逻辑完全不适合在正式项目中作为DI方案使用：
  • 无统一的服务注册抽象，无法建立接口与实现类的映射关系
  • 不支持单例、作用域等生命周期配置，所有解析出的依赖均为瞬时实例，缺少统一的托管资源释放机制
  • 对嵌套依赖的解析能力极弱，只要依赖链中某一环缺少无参构造函数，解析流程会直接抛出类型加载异常
• 实际MVC5项目中若要使用DI，通用做法是替换掉默认的DefaultControllerFactory，接入Autofac、Unity等成熟第三方DI容器的适配模块，不会使用这套内置的简易解析逻辑。

内容的提问来源于stack exchange，提问作者Martin Zaloga