IoC - 对象实例的动态组合

发布于 2024-09-05 16:45:49 字数 487 浏览 5 评论 0原文

有没有办法使用 IoC、MEF [Imports] 或其他 DI 解决方案在对象创建时(而不是在组合期间)动态组合依赖项?

这是我目前的想法。如果您有一个引发事件的对象实例,但您不是一次创建该对象并将其保存在内存中,则必须在每次创建该对象时注册事件处理程序。据我所知,大多数 IoC 容器要求您注册组合中使用的所有类并调用 Compose() 以使其连接所有依赖项。

我认为这可能是一个可怕的设计(我在这里处理一个遗留系统),由于对象创建、依赖注入等的开销,这样做是很糟糕的……但我想知道是否可以使用一种新兴的 IoC技术。

也许我混淆了一些术语,但我的目标是避免编写一个框架来“连接对象实例上的所有事件”,并使用 MEF 之类的东西来[导出]处理程序(依赖项),这些处理程序遵循非常严格的规则特定接口并将它们 [ImportMany] 导入到一个对象实例中,因此如果应用程序启动时程序集存在,我的导出就会被调用。因此,也许在应用程序启动时所有对象仍然可以组合,但我希望系统在创建和销毁对象时找到并调用所有对象。

Is there a way using IoC, MEF [Imports], or another DI solution to compose dependencies on the fly at object creation time instead of during composition time?

Here's my current thought. If you have an instance of an object that raises events, but you are not creating the object once and saving it in memory, you have to register the event handlers every time the object is created. As far as I can tell, most IoC containers require you to register all of the classes used in composition and call Compose() to make it hook up all the dependencies.

I think this may be horrible design (I'm dealing with a legacy system here) to do this due to the overhead of object creation, dependency injection, etc... but I was wondering if it was possible using one of the emergent IoC technologies.

Maybe I have some terminology mixed up, but my goal is to avoid writing a framework to "hook up all the events" on an instance of an object, and use something like MEF to [Export] handlers (dependencies) that adhere to a very specific interface and [ImportMany] them into an object instance so my exports get called if the assemblies are there when the application starts. So maybe all of the objects could still be composed when the application starts, but I want the system to find and call all of them as the object is created and destroyed.

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

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

发布评论

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

评论(1

天生の放荡 2024-09-12 16:45:49

通常,在 DI/IoC 环境中处理动态实例化的方法是使用抽象工厂。工厂是唯一允许与容器直接交互的类类型,以便在实例化新对象时解决依赖关系。

public interface IWidgetFactory
{
    IWidget CreateWidget(...);
}

public class MyIocWidgetFactory : IWidgetFactory
{
    private IoCContainer container;

    public MyIocWidgetFactory(IoCContainer container)
    {
        if (container == null)
            throw new ArgumentNullException("container");
        this.container = container;
    }

    public IWidget CreateWidget(...)
    {
        // Assumes that the container is configured to create transient objects
        // for IWidget, not a singleton.
        return container.Resolve<IWidget>();
    }
}

请不要将此与服务定位器反模式混淆;不允许任何其他东西接触容器,只有工厂,并且它只创建一种类型的对象。

此时,您只需将 IWidgetFactory 传递给在运行时创建小部件所需的任何内容。就是这样 - 你已经维护了 DI。

Typically the way you handle on-the-fly instantiation in a DI/IoC environment is to use abstract factories. The factory is the only type of class allowed to interact directly with the container, in order to resolve dependencies when instantiating a new object.

public interface IWidgetFactory
{
    IWidget CreateWidget(...);
}

public class MyIocWidgetFactory : IWidgetFactory
{
    private IoCContainer container;

    public MyIocWidgetFactory(IoCContainer container)
    {
        if (container == null)
            throw new ArgumentNullException("container");
        this.container = container;
    }

    public IWidget CreateWidget(...)
    {
        // Assumes that the container is configured to create transient objects
        // for IWidget, not a singleton.
        return container.Resolve<IWidget>();
    }
}

Please don't confuse this with the service locator anti-pattern; nothing else is allowed to touch the container, just the factory, and it only creates one type of object.

At this point, you just pass around the IWidgetFactory to whatever needs to create a widget at runtime. That's it - you've maintained DI.

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