MEF:“容器”的作用、生命周期和知识是什么?

发布于 2024-08-27 13:36:31 字数 725 浏览 2 评论 0原文

我正在使用 MEF,在示例中我看到了这段代码(我称之为 MEF 撰写代码):

var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly());
var container = new CompositionContainer(catalog);
container.ComposeParts();

在大多数示例中,这是在与启动程序类以及所有其他接口相同的源文件中完成的和课程。

现在我想使用 MEF,但我想知道这个容器是做什么的。据我猜测它会执行导出/导入映射,但是如果我有这段代码(来自 Windows 窗体应用程序:

 [STAThread]
        static void Main()
        {
            Application.Run(new Form1());

        }

并且在该 Form1 中我想创建一个 Auditer 类型的对象(它具有 ILogger 类型的属性标记为导入) 会怎么样? ,并且我有一个实现 ILogger 标记导出的类,

是否必须将 MEF 撰写代码放在 Form1 的 Load 事件中,或者放在 Auditer 类的构造函数中?

我 当我将它(MEF 撰写代码)放在 Auditer 类的构造函数中时,但我读到的示例以某种方式让我觉得您只需调用一次撰写代码。

i'm playing with MEF and in the example i see this code ( i call it the MEF compose code):

var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly());
var container = new CompositionContainer(catalog);
container.ComposeParts();

In most examples this is done in the same source file as the Startup Program class lives, as well as all of the other interfaces and classes.

Now i want to use the MEF, but i wonder what this container does. As far as i guessed it does the export / import mapping, but what if i have this code (from a windows forms app:

 [STAThread]
        static void Main()
        {
            Application.Run(new Form1());

        }

and in that Form1 i want to create an object of type Auditer (which has a property of type ILogger marked import, and i have a class implementing ILogger marked export).

Do i have to place the MEF compose code in the void Main(), in the Load event of Form1, or in the constructor of the Auditer class?

I only get it to work when i put it (the MEF compose code) in the constructor of the Auditer class, but the examples i read somehow give me the idea that you only have to call the compose code once.

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

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

发布评论

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

评论(1

猫性小仙女 2024-09-03 13:36:31

CompositionContainer 是实际在 MEF 中组合您的部件的类。

当您想要使用 MEF 时,您需要始终将归因于导入定义的部分组合起来。如果 Form1 中有一个标有 [Import(typeof(ILogger))] 的属性,则在某些时候,您需要撰写 您的 Form1 实例。

CompositionContainer 是实际执行此组合的类。它根据容器内包含的目录查找适当的导出 ILogger,并构造类型、将导出与导入相匹配等。MEF

仅“组合”一次的原因是通常,使用 DI,您将在应用程序开始时构建和设置容器的单个实例,并且它将组成您的“主”窗口。如果将所有其他类用作主窗口的一部分,则它们将自动组合。 (例如,如果 Form1 组成一个 ILogger,但您的 ILogger 实现有自己的 [Import],它也将在该过程中组成。)话

虽这么说,但没有固定的规则指定您不能多次创作。例如,在 WPF 和 Silverlight 中,MEF 通常无法构造您的对象,这意味着它无法自动为您组合对象。在这些情况下,常见的模式是使用 CompositionInitializer(在 Silverlight 中的框中,而不是在桌面中)根据静态目录让部件自行组合。 我最近在博客中介绍了 WPF 的这种方法

对于 Windows 窗体,这可能不太必要,因为没有第三方产品(XAML 解析器)来构造您的类型。但是,如果您选择的话,您仍然可以使用相同的方法。

The CompositionContainer is the class that actually composes your parts in MEF.

When you want to use MEF, you need to always compose the part that's attributed with the import definitions. If you have a property in Form1 that's marked with [Import(typeof(ILogger))], at some point, you'll need to compose your Form1 instance.

The CompositionContainer is the class that actually performs this composition. It finds the appropriate exported ILogger based off the Catalog(s) contained within the container, and constructs types, matches exports to the imports, etc.

The reason that the MEF samples only "compose" one time is that, often, with DI, you'll have a single instance of the container constructed and setup at the beginning of the application, and it will compose your "main" window. All other classes will be composed automatically if they're being used as part of the main window. (For example, if Form1 composes an ILogger, but your ILogger implementation has an [Import] of it's own, it too will get composed in that pass.)

That being said, there is no fixed rule that specifies you can't compose more than once. In WPF and Silverlight, for example, it's frequent that MEF can't construct your object, which means it can't automatically compose your object for you. In these situations, a common pattern is to use the CompositionInitializer (in the box in Silverlight, not in the desktop) to have parts compose themselves, based off a static catalog. I recently blogged about this approach for WPF.

With Windows Forms, this may be less necessary, since there isn't a third party product (the XAML parser) constructing your types. However, you could still use this same approach, if you so choose.

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