假设我有一个通用的 WCF 服务和控制台应用程序项目，它们不会在特定于客户端的部署中发生变化。我在公共项目中有一些由特定客户端代码实现的接口。客户端代码显然会从客户端更改为客户端。我认为这将是 IoC 容器的适当用途。在我的常见服务项目中，我将客户端特定的 dll 放在 bin 中，并通过 IoC 连接依赖项。唯一的技巧是这必须动态完成，因为公共服务项目不能直接引用特定的客户端项目。不过也没什么大不了的。
这是对 IoC 容器的正确用法吗？
【问题讨论】：
标签： c# .net dependency-injection inversion-of-control structuremap
如果我正确理解了您的系统，也许您可以从查看Managed Extensibility Framework 中受益。
【讨论】：
依赖注入 (DI - 你称之为 IoC) 与支持插件/插件略有不同。
DI 的目的是管理依赖关系并减少系统不同部分之间的耦合。它可能有点像加载项，但略有不同，因为您通常只是将接口的一种实现替换为另一种实现。
另一方面，使用插件，其目的是提供相同服务的零个、一个或多个实现。
在这两种情况下，您可能希望在运行时根据配置文件、扫描文件夹或类似的方式解决实现，因此存在很大程度的重叠。
使事情变得更加复杂的是，加载项本身可能具有依赖关系，您可能希望支持它（进入 DI 领域）。
对于 Add-In 方案，我将支持 Konamimam 的建议：MEF 听起来很符合您的要求。
【讨论】：
是的，这可以正常工作。您只需要确保客户端特定的 DLL 带有它们自己的注册。使用 StructureMap，它将被实现为客户端特定 DLL 中的注册表类。
【讨论】：