从模块/插件配置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，但我确实知道它非常轻量级，因此可能没有多大意义。