Provider/Listener vs Event/Handler

Topics: Enterprise Library Core, General discussion
Dec 18, 2007 at 9:03 AM
What is the difference between Provider/Listener schema and Event/Event Handler?

Provider and Listener linked by the class name, how will inherentence affect this?

Is Providre/Listener more easy? Is Event/Event Handler more flexible?

Event/Handler support dynamic linking, Does Provider/Listener also support this?

Thank you.
Dec 18, 2007 at 10:46 AM
Hi,

Are you asking about the instrumentation providers and listeners, or is this a more generic question? Please clarify.

Fernando
Dec 18, 2007 at 12:27 PM

fsimonazzi wrote:
Hi,

Are you asking about the instrumentation providers and listeners, or is this a more generic question? Please clarify.

Fernando


The "instrumentation" provider.

I used DAAB v1.0 years ago, but did not really track the refactoring of Enterprise Library. Today I tried t read the v3.1 documents, found quite some new things.

Inside tracing/logging module, there're also instrumentation providers. Seems this is an important (new) concept in dotnet?

Thank you.

Dec 18, 2007 at 1:58 PM
Hi,

These are really not comparable. The Provider/Listener approach for instrumentation in EntLib is really a local design decision that helps decoupling the logical block events from the concrete instrumentation used to represent them, and .NET events and event handlers are used for its implementation (the provider exposes events and the listener attaches its handlers to these events). The name matching is really just a convention, and attributes are used to link them together and to match events with their handlers; however, when maximum performance is required custom code is used to match events with their handlers.

There is some information about this in the help file; look at the topic in ms-help://MS.VSCC.v80/MS.VSIPCC.v80/ms.EntLib.2007May/EnterpriseLibrary/html/00-240-Instrumentation.htm.

Regards,
Fernando
Dec 19, 2007 at 4:01 AM
Edited Dec 19, 2007 at 4:05 AM

fsimonazzi wrote:
Hi,

These are really not comparable. The Provider/Listener approach for instrumentation in EntLib is really a local design decision that helps decoupling the logical block events from the concrete instrumentation used to represent them, and .NET events and event handlers are used for its implementation (the provider exposes events and the listener attaches its handlers to these events). The name matching is really just a convention, and attributes are used to link them together and to match events with their handlers; however, when maximum performance is required custom code is used to match events with their handlers.

There is some information about this in the help file; look at the topic in ms-help://MS.VSCC.v80/MS.VSIPCC.v80/ms.EntLib.2007May/EnterpriseLibrary/html/00-240-Instrumentation.htm.

Regards,
Fernando


Yeah I read this help page, I'm doing another project to dynamically load assemblies and link up Event with Event Handlers, so I found Provider/Listener and Event/Handler similar, maybe comparable in some way.

As this page introduces,

we could use
InstrumentationListener
InstrumentationProvider
InstrumentationConsumer
to instrument an application and a listener.

Sample source for provider:

InstrumentationListener(typeof (MyListener))
public class MyApplication
{
InstrumentationProvider("DbConnect")
public event EventHandler<EventArgs> OnDbConnect;
}

Sample source for listener;

public class MyListener
{
public MyListener(string instanceName, bool a, bool b, bool c) {}

InstrumentationConsumer("DbConnect")
public void ConnectObserved(object sender, EventArgs e)
{
Console.WriteLine("I saw a Database Connect.");
}
}

So here the compiler did the job to connect the Event OnDbConnect in Class MyApplication to the Event Handler ConnectObserved in class MyListener, by the indicator DbConnect.

In my program, I did something like this:

I use Class System.Reflection.Assembly 's Method public static Assembly LoadFrom(string assemblyFile) to load an Assembly, given the dll's name;
then I use Class System.Delegate 's Method public static Delegate CreateDelegate(Type type, object target, string method); to create a Delegate;
then I use Class System.Reflection.EventInfo 's Method public void AddEventHandler(object target, Delegate handler); to link the Delegate to the Event;

This works. But not so convenient as the "Provider/Listener" concept, since there the compiler did the linking job.

So my question is
1. In Provider/Listener mode, will inherentance disturb the linking?
For example, if I create another class MyListenerChild inhereting from MyListener, will this work?

2. In Provider/Listener mode, the linking of Provider and Listener, is it done in compiling time or runtime?
For example, if the listener is in an dll, dynamically loaded into running time CodeDom, will the Provider and Listenre be linked together?

Thank you.



Dec 19, 2007 at 10:57 AM
Hi,

First, you need to be aware that this functionality was not designed to be used independently. It may suit your purposes, but it may also be less convenient than a direct approach.


So my question is
1. In Provider/Listener mode, will inherentance disturb the linking?
For example, if I create another class MyListenerChild inhereting from MyListener, will this work?

Don't really know. Based on the implementation, I think it should work but I haven't tried it.


2. In Provider/Listener mode, the linking of Provider and Listener, is it done in compiling time or runtime?
For example, if the listener is in an dll, dynamically loaded into running time CodeDom, will the Provider and Listenre be linked together?

It is not the compiler that does the linking; it is done at runtime by invoking specific code. With EntLib it just happens because the code is invoked during the construction process, but if you use this independently you'll need to invoke it yourself at the appropriate time (whatever appropriate means in your scenario).

If you have both the provider and the listener instances, you can do new ReflectionInstrumentationBinder().Bind(provider, listener). If you want a new instance of the listener type specified with attributes you can do new InstrumentationAttachmentStrategy().AttachInstrumentation(provider, configurationSource, reflectionCache), but this is instrumentation specific and requires additional parameters. You may want to extract the listener creation logic from the strategy and use just that in your code.

Fernando