从EventArgs参数公开可用的Type信息. [英] Exposing usable Type info from the EventArgs argument.

问题描述

我的项目使用后期绑定来注册触发事件的DLL.
在DLL中，事件使用其事件参数的自定义类来添加其他信息，例如消息".

换句话说，DLL中的类应类似于以下内容:

My project uses latebinding to register a DLL that fires an event.
Within the DLL the event uses a custom class for it''s Event arguments to add additional info, e.g. "Message".

In other words the class within the DLL should resemble this:

//DLL Project:
public class MyCustomEventArgs : EventArgs
{
    public string message;

    // Rest of the class body...
}

但是，在我的主项目中，我的接收事件方法不了解"MyCustomEventArgs"类型，因此，我的方法仅接收正常的EventArgs，如下所示:

However, within my main project, my receiving event method has no knowledge about the "MyCustomEventArgs" type, and therefor my method merely receives a normal EventArgs, as follows:

//Main project, (late binds the DLL):
public void receivedMessage(object sender, EventArgs e)
{
    //Here I want to be able to extract the "Message" string from e, but how?
}

在这种方法中，我要公开"e"的类型并创建该类型的对象.
我知道这一定有可能，但是解决方案使我望而却步.

In this method I want to expose the type of "e" and create an object of that type.
I know this must be possible, but the solution eludes me.

Thank you in advance!

推荐答案

这个想法很简单.您几乎了解了，应该考虑一下.

您使用的后期绑定类型是插件级别(您的已注册" DLL)和插件体系结构.您需要将其视为整个体系结构，这一切对您来说都是清楚的.这种想法是:宿主应用程序永远不会与插件完全无关，而与实现细节无关.事件参数的具体类型不是其中之一.同样，对于事件自变量的分配，也适用经典的OOP原则.非常感谢您提出的关于后期绑定"的想法:正如OOP所理解的那样，它在后期绑定方面具有很深的类比.

插件体系结构是一个非常有趣的范例，与客户端服务器和其他相当原始的概念不同.您有一个主机应用程序和一些插件.您需要具有一些插件API才能识别某些类和成员引发反射，以便在主机应用程序中使用它们.通常，主机应用程序还为插件提供一些插件API及其实现，因此，插件和主机应用程序将实现其插件相关的接口，并相互传递对该实现的接口引用.

现在，让我们记住，没有奇迹.接口在某处声明.它可以是主机和所有插件实现都引用的单独程序集，但可以完全驻留在主机程序集中. (重要的是要理解，当您加载或引用某个程序集时，"EXE"和"DLL"之间的区别完全无关紧要；这些仅是文件命名约定；文件可以具有任何名称；您可以始终因此，事件参数类型应该在插件接口所在的位置定义，这样主机和插件程序集都可以使用它(很明显).这些以及仅这些事件参数类型可以在主机部分上用作设计时类型.至于运行时类型…，我稍后再考虑，但这取决于您要如何处理它们.但是，在我们去那里之前，让我告诉您，菲利普·斯图克(Philip Stuyck)建议的反射方法不会给您太多帮助.通过反射，您可以发现其他成员，但是您如何知道其语义?

因此，让我们最后回到插件派生的事件参数类型.您可以在此处应用经典OOP的原理.您需要将某些成员的处理方法"与插件所知的如何处理"区分开来.但是，您需要保持这个概念的框架.特别是，您不应尝试将派生类型移回插件界面，标记类型并尝试向下转换.

考虑一下.在插件界面中:

The idea is very simple. You almost got it, should just think about it.

The kind of late binding you use is of the level of plug-in (your "registered" DLL) and the plug-in architecture. You need to look at it as at the whole architecture, and it all will be clear to you. The think is: the host application is never totally agnostic the the plug-in but is agnostic to the implementation detail. The concrete type of event arguments is not one of them. Also, for assignment of event arguments, classical OOP principles apply. And I appreciate you idea on "late binding": this has a deep analogy in late binding as it is understood in OOP.

Plug-in architecture is a pretty interesting paradigm, unlike client-server and other rather primitive concepts. You have a host application and some plug-ins. You need to have some plug-in API to recognize some classes and members throw reflection, to use them in the host application. In general case, the host application also provides some plug-in API and its implementations to the plug-ins, so a plug-in and a host application implement their plug-in related interfaces and pass to each other the interface references to those implementation.

Now, let''s remember that there is no such thing as a miracle. The interfaces are declared somewhere. It can be a separate assembly referenced by both the host and all plug-in implementations, but it can fully reside in the host assembly. (It''s important to understand that when you load or reference some assembly, the difference between "EXE" and "DLL" is totally insignificant; those are nothing more then file naming conventions; the files can have any names; you can always reference a host assembly by plug-in.) So, the event argument type should be defined in the same place where the plug-in interfaces are, so both host and plug-in assemblies could use it (quite apparently). These and only these event argument types can serve as a design-time type on the host part. As to the run-time type… I''ll consider it later, but it depends on what you want to do with them. But before we go there, let me tell you that the reflection approach Philip Stuyck suggested won''t give you much. With reflection, you can discover additional members, but how would you know its semantic meaning?

So, let''s finally go back to the plug-in derived event argument types. You can apply the principle of classic OOP here. You need to isolate "what to do with it" for some member from "how to do it" which is known to the plug-in. However, you need to stay in the framework of this concept. In particular, you should not try to move derived types back to the plug-in interface, tag the types and try down-casting.

Consider this. In the plug-in interfaces:

abstract class PluginEventArgs : EventArgs {
    void KnowWhatToDoWithIt() {
        Info = KnowHowToDoIt();
        // use Info
    }
    protected abstract string KnowHowToDoIt();
    internal string Info; //string is lame, but this is only for the sample
}

在插件中:

In plug-in:

class ThisPlugInEventArgs : PluginEventArgs {
    protected override string KnowHowToDoIt() {
        // use someField
        // use something else
        return // something
    }
    MyType someField;
}

非常粗略-仅是提出一个想法.

祝你好运，

—SA

Very roughly — just to give an idea.

Good luck,

—SA

您需要一个额外的dll(库)，其作用类似于动态加载的dll与应用程序之间的桥梁.只有应用程序和动态加载的dll都使用或打算使用的常见类型，才应移至第三个dll.
这样，您不必复制类定义.
其他解决方案将涉及反思.但是实际上，如果要在应用程序中获取消息，则说明您已经具有依赖项.
因此，答案是在库中创建一个通用的自定义eventargs.

You need an extra dll (library) that acts like a bridge between your dynamically loaded dll and your application. Only the common types, that are used or meant to be used by both your application and the dynamically loaded dll should move to this third dll.
This way you do not have to replicate class definitions.
Other solutions would involve reflection. But actually if withing your application you want to get the message, you kind of already have a dependency.
So the answer is to create a common custom eventargs in a library.

这篇关于从EventArgs参数公开可用的Type信息.的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！