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

发布于 2024-08-27 01:14:50 字数 367 浏览 13 评论 0原文

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

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

我真的希望你能理解我的观点,我知道我的英语很糟糕(我来自非英语国家:) 多谢 !

i am in big dilema..
I am working on highly modular web app in ASP.NET MVC 2 (in fact, core will be super lightweight, all work on modules/plugins). I found MEF pretty useful for modules discovery, but i dont want to us it as IoC container. There is pretty good chance that I will need advanced features of "true" IoC container, so I would like to use Unity.

And here is the problem : how to allow modules to configure container (programatically) = register their own types (mvc controllers, custom implementations of services...) at application start without making hard dependency on Unity in all modules ?
I know about Common Service Locator project, and it seems pretty good, but this interface co container only allows resolving types, not registering them (afaik).

I really hope you can understand my point, I know my english is terrible (I am from non english speaking country :)
Thanks a lot !

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦里的微风 2024-09-03 01:14:50

我当然可以理解不想使用 MEF 作为 DI 容器,但我认为您仍然应该考虑这是否不适用于您的加载项。

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

应用 MEF 属性就是组件注册。

如果您确实不想使用 MEF,那么您只有几个其他选项(没有一个特别有吸引力):

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

I can certainly sympathize with not wanting to use MEF as a DI Container, but I think you should still consider whether that might not be applicable for your add-ins.

You already require your add-ins to use MEF, so they will all have a hard dependency on it. While I personally don't like the hard-coded, attribute-based approach used by MEF, it sounds like you are asking how each add-in can register itself with the DI Container. That also sounds like hard-coding to me, so you might as well just use MEF all the way in.

Applying MEF attributes is component registration.

If you really don't want to use MEF you only have a few other options (none of them particularly more attractive):

  • Require all add-ins to also take a hard dependency on Unity. I completely understand why you don't want to do this, but I'm just including this option for the sake of completeness
  • Require all add-ins to also take a hard dependency on Common Service Locator. In my view, this only shifts the problem slightly.
  • Define your own add-in registration interface that all add-ins must implement. You can then write your own implementation that uses Unity, so that all add-ins register themselves against this interface, but then you would more or less just be duplicating the features of MEF.
  • Write all add-ins in a DI-friendly, but container-agnostic style. This leaves the problem with configuring the DI Container, and you will then have to resort to XML configuration for that. This is a very brittle approach and can quickly lead to maintainance hell, so once again I'm just including this option for the sake of completeness.

Using MEF for add-ins doesn't preclude you from using Unity in your core application, but I do understand that it's very lightweight, so that may not make a lot of sense.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文