在使用不使用 IoC 的库的应用程序中使用 IoC答案

【问题标题】：Using IoC in an application that use a library that doesn't use IoC在使用不使用 IoC 的库的应用程序中使用 IoC
【发布时间】：2013-03-04 03:21:32
【问题描述】：

我目前正在使用一个库 (SuperWebSocket)，它是一个 websocket 服务器库，它使用引导程序知道从配置文件中加载哪些实例。我已经为此实现了一个引导类（但是没有使用 IoC 加载实例）。来自该服务器的命令也是从程序集反射加载的。我想将此服务器与使用 IoC 的 DAL 和服务层结合使用。 我的主要问题是我无法找到一种方法将这个控制台应用程序（服务器）和与 lib 的合作放入 IoC 场景中，而不必最终使用 ServiceLocator。

通常内核（Ninject）应该位于组合根（看起来是许多周围的最佳实践..），在这种情况下这是不可能的，或者至少我没有发现如何这样做这就是我在这里的原因。这些命令也是从程序集反射加载的。我可以实现一个 CommandLoader 但这仍然是一个问题，因为它们都继承自同一个接口（可能是多重绑定？）。我可以为它们中的每一个制作自定义界面，但我仍然找不到自动加载它们的方法。即使我找到了加载它们的方法，我仍然必须能够从属性中获取服务，这并不容易。

有什么建议吗？

【问题讨论】：

为什么不将外部库封装在您自己的适配器中，该适配器使用您的 IoC 容器？无论如何，将第三方库保留在一个地方并对其进行抽象是一种很好的做法，以防您需要将它们换成其他东西或以不同方式处理特定情况。

标签： c# inversion-of-control ninject console-application service-locator

【解决方案1】：

如果我正确理解了您的问题，那么图书馆就是完成所有工作的入口点。在这种情况下，它取决于框架要做什么。以下是您可以做的一些事情，第一件事是首选：

检查库并找到某种方法来挂钩框架以拦截对象的创建。
在库创建对象后调用kernel.Inject(this)。看看Ninject.Web 扩展。在那里我们添加了一些基类，例如NinjectWebPage 为 WebPage。这个新的基类在创建后调用 kernel.Inject。现在可以从该基类派生新网页，并使用属性注入来获取依赖项。
在库创建的对象中使用ServiceLocator 模式。但就在这个层面。任何更深层次的东西都应该使用依赖注入。

【讨论】：

解决方案 3 对我来说似乎很好。所有逻辑都位于可以被 Ninject 拦截的命令中。对于细节，我可以使用 servicelocator，但至少我的命令可以重复使用并且可以互换，这使得 ioc 的使用在这里非常有用。一个很大的优点是这将使我的命令可测试，这是这里的主要目标。感谢 Remo 抽出时间来回答这个问题。