我基本上了解 IoC 框架的工作原理，但我不太明白的一件事是基于代码的配置应该如何工作。使用 XML，我了解如何将新程序集添加到已部署的应用程序，然后更改 XML 中的配置以包含它。如果应用程序已经部署（即以某种形式编译），那么如何在不重新编译的情况下进行代码更改？还是人们就是这样做的，只需更改代码中的配置并重新编译？
【问题讨论】：
标签： xml dependency-injection inversion-of-control
热交换依赖并不是使用 DI 容器的唯一目标。
依赖注入 (DI) 是帮助我们开发松散耦合代码的原则。松散耦合仅意味着我们可以独立地改变消费者和服务。 我们如何在这个级别上没有解决这个问题。
DI 容器 是帮助一起使用连线依赖项的框架。它们或多或少只是帮助我们应用 DI 模式的实用程序库。再一次，如何我们配置容器与我们如何使用这些依赖项是垂直的。
XML 配置 允许我们更改容器配置无需重新编译。代码作为配置没有。
然而，在不重新编译的情况下交换依赖项通常只与所有松散耦合代码的小子集相关。对于其余部分，基于约定的方法更有效，因为它往往不那么脆弱。请参阅here 了解更多信息。
【讨论】：
IoC 和 Dep 注入有助于在不重新编译的情况下进行更改（取决于使用的工具），但不是必需的。使用代码进行配置是关于配置容器，而不是关于部署后的更改。是的，如果您更改代码，通常需要重新编译。
【讨论】：
在不重新编译的情况下更改代码，是不可能的。在不重新加载应用程序池的情况下更改存储在 Web.Config 中的配置是不可能的。但是，您可以采用以下方案，您不必重新编译代码或回收应用程序池。
1. 将您的映射存储在外部配置文件中。 （XML 很好）
2. 编写一个函数，从外部文件加载映射到
你的容器。
3. 公开一个重新加载映射的函数。
4. 每当您想重新加载映射时，只需调用暴露的
方法，你很高兴:)
您还可以将映射存储在 SQL 服务器或任何其他位置。 （只需将它们加载到容器处理所需的格式即可。）
【讨论】：
仅仅因为 DI 容器使用代码进行配置并不意味着不重新编译就不能更改任何配置。它确实要求您准确考虑您希望以这种方式配置的内容，并提供一些更改该配置的方法（例如通过属性文件）。
【讨论】：