gpt4 book ai didi

c# - 插件架构中的 DI (Autofac) : Is one separate DI container per plug-in OK?

转载 作者:太空狗 更新时间:2023-10-29 18:33:15 27 4
gpt4 key购买 nike

我正在尝试将 DI(使用 Autofac)引入现有的 Windows 窗体应用程序。

此应用程序有一个基本的插件架构,其中每个插件都显示自己的表单。在启动时,应用程序会扫描已注册的程序集以查找实现 IPlugin 的类型,然后使用 Activator.CreateInstance 激活它们:

public interface IPlugin
{
Form MainForm { get; }
}

不能改变这个给定的框架。这意味着,每个插件类都是通过非 DI 方式实例化的,因此在我看来,我必须为每个插件引导一个单独的 DI 容器。

我的问题是,是否可以为每个插件创建一个单独的 ContainerBuilder 和容器并且仍然相当有效? (将有大约 10 个不同的插件。)还是整个应用程序应该只有一个 DI 容器?

我在下面提供了我当前解决方案的一些示例代码。


using Autofac;
using System.Windows.Forms;

public class Plugin : IPlugin // instantiated by Activator
{
public Form MainForm { get; private set; }

public Plugin() // parameter-less constructor required by plugin framework
{
var builder = new ContainerBuilder();
builder.RegisterModule(new Configuration());
var container = builder.Build();

MainForm = container.Resolve<MainForm>();
// ^ preferred to new MainForm(...) because this way, I can take
// advantage of having dependencies auto-wired by the container.
}
}

internal class Configuration : Module
{
protected override void Load(ContainerBuilder builder)
{
builder.RegisterType<MainForm>().SingleInstance();
// ... more plugin-specific registrations go here...
}
}

internal class MainForm : Form { /* ... */ }

我也不确定是否在插件构造函数中创建一个容器然后简单地忘记它,但让它在后台进行 Autowiring ,可以吗?

最佳答案

容器的使用最好遵循 Register Resolve Release pattern (存款准备金率)。我知道您说过您不能更改当前的 Activator.CreateInstance 用法,但它仍然有助于理解它真正应该如何使用。

如果您没有该约束,则应该只有一个容器实例,由父应用程序本身托管。然后可以使用它来组合所有插件。这将使插件能够共享依赖关系。这是 MEF 采取的路线,它也解决了可扩展性场景。

现在,既然您不能那样做,那么您可以做的下一个最好的事情就是按照您的建议为每个插件设置一个容器。那时它主要成为一个实现细节。在每个插件中,您仍然应该遵循 RRR 模式。

会不会效率低下?除非你有很多插件并且一直在创建和销毁它们,否则几个不同的容器应该没什么大不了的。但是,测量比创建过早的优化更好。

在这种情况下,您只能通过将容器设为静态来共享容器。然而,这会使事情变得比他们需要的更复杂,所以除非绝对必要,否则不要走那条路。

关于c# - 插件架构中的 DI (Autofac) : Is one separate DI container per plug-in OK?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3940675/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com