The SimbaEngine SDK includes a flexible logging system for use in development, troubleshooting, and maintenance of any ADO.NET provider developed with it. This article will go through how the logging system is set up in the .NET DSI. It is expected that readers have a basic understanding of the SDK and the DSI before reading this article.
The logging system uses the interface ILogger as a top-level object. In brief, this interface defines functions for logging messages at different levels, as well as the ability to change the logging level. Please see the documentation for a complete description of the methods and behaviour of ILogger.
The SDK supplies a default implementation, DSILogger, which logs to a text file. This enables you to get started developing your driver with a fully functional logging system out of the box. For more information please refer to Enable Logging in ADO.NET.
However, if you do not wish to use the logging that is provided by the SDK, then you are free to subclass ILogger and implement your own logging implementation. A common use case for this would be to tie the ADO.NET provider logging into an existing database logging system.
The ADO.NET layer accesses the DSII ILogger instances through the IDriver, the IEnvironment, the IConnection, and the IStatement. Each of these classes contains a function to get the ILogger instance for that object. The SDK, by default, returns the ILogger instance associated with the IDriver for all 4 objects. You may want to change this behaviour and provide a separate ILogger object for any of these objects. One case may be for each IConnection object to have its own ILogger to allow you to more easily debug situations that involve many simultaneous connections.
Your ILogger implementation should allow for multi-threaded access, as they will be shared across threads if your ADO.NET provider is being accessed by multiple threads at the same time.
The .NET DSI also supplies the LogUtilities class, which greatly simplifies the use of your ILogger instance through the use of reflection. Instead of having to explicitly specify the package and class where the message originates, the LogUtilities class will automatically determine these parameters. The LogUtilities also allows for passing and logging of function parameters when logging a function entrance. Please see the documentation for a complete description of the methods of LogUtilities.