从模块/插件配置 IoC 容器？

Question

我处于两难境地.. 我正在 ASP.NET MVC 2 中开发高度模块化的 Web 应用程序（事实上，核心将是超级轻量级​​的，所有模块/插件都可以工作）。我发现 MEF 对于模块发现非常有用，但我不想将它用作 IoC 容器。我很有可能需要“真正的”IoC 容器的高级功能，所以我想使用 Unity。

这里的问题是：如何允许模块（以编程方式）配置容器 = 在应用程序启动时注册自己的类型（mvc 控制器、服务的自定义实现......）而不在所有模块中对 Unity 产生硬依赖？ 我知道 Common Service Locator 项目，看起来还不错，但是这个接口 co 容器只允许解析类型，而不是注册它们（afaik）。

我真的希望你能理解我的意思，我知道我的英语很糟糕（我来自非英语国家:) 非常感谢！

Answer 1

我当然可以同情不希望将 MEF 用作 DI 容器，但我认为您仍然应该考虑这是否可能不适用于您的加载项。

您已经要求您的加载项使用 MEF，因此它们都将严重依赖它。虽然我个人不喜欢 MEF 使用的硬编码、基于属性的方法，但听起来您在问每个加载项如何将自己注册到 DI 容器。这对我来说听起来也像是硬编码，所以你不妨一直使用 MEF。

应用MEF属性是组件注册。

如果您真的不想使用 MEF，您只有几个其他选择（没有一个特别有吸引力）：

• 要求所有插件也对 Unity 有硬依赖。我完全理解您为什么不想这样做，但为了完整起见，我只是包含此选项
• 要求所有加载项也对 Common Service Locator 具有硬依赖。在我看来，这只会稍微改变问题。
• 定义您自己的加载项注册接口，所有加载项都必须实现。然后，您可以编写自己的使用 Unity 的实现，以便所有加载项都针对此接口注册自己，但您或多或少只是在复制 MEF 的功能。
• 以DI-friendly, but container-agnostic 样式编写所有加载项。这留下了配置 DI 容器的问题，然后您将不得不为此求助于 XML 配置。这是一种非常脆弱的方法，很快就会导致维护地狱，所以为了完整起见，我再次包含此选项。

将 MEF 用于插件并不妨碍您在核心应用程序中使用 Unity，但我知道它非常轻量级，因此可能没有多大意义。