2

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

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

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

4

1 回答 1

2

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

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

应用 MEF 属性是组件注册。

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

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

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

于 2010-03-25T09:28:18.963 回答