使用 IoC 容器的合适情况？
假设我有一个通用的 WCF 服务和控制台应用程序项目，它们不会在特定于客户端的部署之间发生变化。我在常见项目中有一些由特定客户端代码实现的接口。客户端代码显然会因客户端而异。我认为这对于 IoC 容器来说是一个合适的用途。在我的公共服务项目中，我将客户端特定的 dll 放入 bin 中，并通过 IoC 连接依赖项。唯一的技巧是，这必须动态完成，因为公共服务项目无法直接引用特定的客户端项目。不过没什么大不了的。
这是 IoC 容器的正确用法吗？
Let's say I have a common WCF service and console app project that do not change across client specific deployments. I have some interfaces in the common projects that are implemented by specific client code. The client code obviously changes from client to client. I'm thinking this would be an appropriate use for an IoC container. In my common service projects, I drop the client specific dll in the bin and wire up the dependencies via IoC. The only trick is that this has to be done dynamically as the common service projects can't have a direct reference on a specific client project. Not a big deal though.
Is this correct usage of an IoC container?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我正确理解您的系统，也许您可以从查看托管扩展性框架中受益。
If I understood correctly your system, maybe you can benefit from taking a look at the Managed Extensibility Framework.
依赖注入（DI - 你所说的 IoC）与支持插件/插件略有不同。
DI 的目的是管理依赖关系并减少系统不同部分之间的耦合。它感觉有点像外接程序，但略有不同，因为您通常只需将接口的一种实现替换为另一种实现。
另一方面，使用加载项的目的是提供零个、一个或多个相同服务的实现。
在这两种情况下，您可能希望根据配置文件、扫描文件夹或类似内容在运行时解析实现，因此存在很大程度的重叠。
使事情变得更加复杂的是，加载项本身可能具有依赖性，并且您可能希望支持这一点（进入 DI 领域）。
对于外接程序场景，我会赞同 Konamimam 的建议：MEF 听起来很适合您的要求。
Dependency Injection (DI - what you call IoC) is a slightly different beast than supporting Add-Ins/PlugIns.
The purpose of DI is to manage dependencies and decrease coupling between different parts of a system. It can feel a bit like Add-Ins, but is slightly different because you usually just replace one implementation of an interface with another.
With Add-Ins, on the other hand, the purpose is to provide zero, one, or many implementations of the same service.
In both cases you may want to resolve the implementations at run-time based on configuration files, scanning a folder or similar, so there's a great degree of overlap.
What makes it even more complicated is that Add-Ins may have depedencies in their own right, and you may want to support that (moving into DI territory).
For the Add-In scenario, I will second Konamimam's suggestion: MEF sounds like it would fit your requirements.
是的，这会很好用。您只需要确保客户端特定的 DLL 带有它们自己的注册即可。使用 StructureMap，它将作为客户端特定 DLL 中的注册表类来实现。
Yes, this will work fine. You just need to make sure the client specific DLLs bring along their own registration. With StructureMap, it would be implemented as Registry classes in the client specific DLLs.