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 回答