Custom Trace Listener and Provider model
A listener is an object that receives the trace output and outputs it somewhere; that somewhere could be a window in your development environment, a file on your hard drive, a Windows Event log, a SQL Server or Oracle database, or any other customized data store. You can think of a Trace Listener as a conduit for passing tracing information from your application to the output store. Application write tracing information on Trace Listeners and Trace Listeners in turn output the tracing information to the target media.
.Net has some in built standard listeners
1. TextWriterTraceListener- Writes the trace output to the xml, csv, text files. There are couple of variants of TextWriterTraceListener
a. XmlWriterTraceListener
b. DelimitedListTraceListener
Above 2 trace listeners are derived from the TextWriterTraceListener and are used for writing the trace information to XML files and CSV files respectively.
2. EventLogTraceListener – It is used to route tracing messages to the Windows event log
3. DefaultTraceListener - This class is used when we want to see the tracing output in the Visual Studio Environment. If there is requirement to capture Trace messages outside of Visual Studio .NET, then some other Trace Listeners must be used.
4. ConsoleTraceListener – Writes the trace information to the console output.
.NET framework provides the flexibility of writing custom Trace Listeners. In order to implement custom Trace Listener, it must be inherited from TraceListener class. Typically a custom trace listener is used where trace data needs to be saved in some kind of custom data source, now number of custom data sources may vary, for each custom data source a separate listener needs to be written. There might be requirement to log the same trace data in to different data source. So in that case .Net provider model in combination with custom trace listener comes in handy. Below is high level diagram of how to use same custom trace listeners accross diffrent data sources.
In this case Custom trace listener will be generic trace listener and will not be agnostic to any data source. Instead of creating separate listener, different set of providers for each data source will be created; common functionality across the provider will be encapsulated in base provider class. Another advantage with this approach is that if trace data needs to be logged in to the additional data source, then we just need to write another provider specific to that data source and plug it in the config file.
Advantage of using the .Net provider model
1. The main advantage by using the provider model is that, Custom Trace Listener becomes a generic trace listener; it can be configured to trace the data in any of the data source by writing the provider for that data source. If the provider model is not been used then Custom Trace Listener becomes specific to custom data source, and if the trace information needs to be traced in some other data source then new custom trace listener needs to be written right from scratch.
2. If additional tracing information needs to be passed, then provider model can provide single insertion point, but if it is not been used then it needs to replicated to all the custom listeners.
3. No need to explicitly instantiate classes. The .NET framework will automatically manage class instantiation, including re-using classes that have already been instantiated. This improves the memory management of your application.
4. Switching data sources is much easier. Changing the data source of trace data is a simple as replacing your existing concrete (implementer) class with a new concrete (implementer) class and inheriting from your provider class. Code in the custom trace listener remains unchanged, thereby reducing effort required to switch data sources and the amount of regression testing required thereafter.
