应自定义MEF的哪些部分以在分布式应用程序中动态加载插件 [英] Which parts of MEF should be customized for dynamic loading of plug-ins in a distributed application

问题描述

我的模拟应用程序将使用插件来提供模拟算法和数据结构，用于存储模拟数据.该应用程序包括两个部分.首先是提供UI(作为WPF UI或作为CAD应用程序的插件)的宿主应用程序.该应用程序处理与用户的所有交互，但不执行任何模拟计算，也不存储任何模拟数据.第二部分是执行模拟计算的数据应用程序.数据应用程序无法让用户直接与之交互，所有输入都是通过与主机的连接来提供的(如果两者都在同一台计算机上，则通过命名管道；如果它们在不同的计算机上，则通过TCP).这种方法允许通过具有多个数据应用程序的单个主机进行分布式计算.

My simulation application will be using plug-ins to provide the simulation algorithms and data structures for the storage of the simulation data. The application consists of two parts. First is the host application which provides the UI (either as WPF UI or as plug-in to a CAD application). This application handles all interaction with the user but does not perform any of the simulation calculations, neither does it store any of the simulation data. The second part is the data application which performs the simulation calculations. The data application does not have any way for the user to interact with it directly, all input is provided via a connection with the host (either via named pipe if both are on the same machine or via TCP if they are on different machines). This approach allows distributed computing via a single host with multiple data applications.

数据应用程序通过一个或多个插件提供了数据存储方法，模拟算法等，因此可以轻松添加新功能.为了使它起作用，计划是:

The data application is provided with the data storage methods, simulation algorithms etc. via one or more plug-ins so that it is easy to add new capabilities. In order for this to work the plan is to:

• 让主机应用程序执行插件搜索.主机应存储描述插件及其元数据的数据，但绝不会实例化任何插件类.为了防止将程序集加载到主机应用程序中，有必要以某种序列化格式存储插件的描述.
• 数据集应用程序将向主机请求插件信息，确定要加载的插件，请求传输正确的程序集(对于分布式计算是必需的)并加载插件.
• 选择正确的插件应基于Type(如System.Type)和其他信息，例如优先级等.

要使所有这些都起作用，我认为我必须:

For all of this to work I think I will have to:

• 为数据应用程序编写某种延迟加载目录(类似于Silverlight中的DeploymentCatalog).诀窍可能是仅在应用程序确定需要实例化哪些类之后才请求转移和加载程序集.
• 为主机应用程序编写我自己的程序集扫描机制，该程序以某种序列化(字符串?)格式存储插件信息，以防止将插件程序集加载到主机应用程序中.
• 编写某种加载机制，可以选择正确的插件类，并确定如何加载它以及要提供的构造参数.
• 找到允许插件指定设置值(包括默认值和所述值的本地化描述)和元数据的某种方式.

我想做的工作尽可能少，所以我看了一些适用于.NET的插件系统.从外观上看，MEF似乎是最有前途的候选人.我已经阅读了MEF的体系结构和功能，但是对于应该集中精力精力的领域，我仍然有些困惑.因此，我的问题是必须定制MEF的哪些部分才能使MEF与我计划的方法一起工作?

I would like to do as little work as possible and so I had a look at some of the available plug-in systems for .NET. From the looks of it MEF seems to be the most promising candidate. I have read up on the architecture and abilities of MEF but I am still a bit in the dark as to where I should be focussing my energy. So my question is which parts of MEF will have to be customized in order to make MEF work with my planned approach?

推荐答案

事实证明，MEF缺少延迟加载插件程序集所需的某些位，但是可以在其中使用MEF的某些部分该应用程序的插件部分.

It turns out that MEF is missing certain bits that are required for the delay loading of plug-in assemblies, however it is possible to use some parts of MEF in the plug-in part of the application.

• 通过实现AppDomain.AssemblyResolve事件的处理程序来延迟加载组件.此解析器使用现有的通信功能(在主机应用程序和数据集应用程序之间进行通信所必需)来传输所需的程序集.
• 按照相关问题的答案中的说明实施插件数据的扫描和序列化.这部分大量使用MEF进行插件数据的检测和序列化.
• 在MEF中似乎不可能在不实例化对象的情况下组成部分，因此，根据此

• Delay loading of the components is done by implementing a handler for the AppDomain.AssemblyResolve event. This resolver uses the existing communication capabilities (which are necessary to communicate between the host application and the dataset application) to transfer the desired assemblies.
• Scanning and serialization of plugin data is implemented as explained in the answer to the relevant question. This part heavily uses MEF to do the detection and serialization of the plug-in data.
• Composing the parts without instantiating the objects seems to not be possible in MEF so this section of the application is implemented as as per the implementation provided by this answer

这篇关于应自定义MEF的哪些部分以在分布式应用程序中动态加载插件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！