Logging was always a nightmare for me! Now I have to implement it again for a proxy system.
In this proxy application, some systems ask proxy system to call some other services.
What I have to log is
- Request Time
- Requester IP
- Request Parameters as XML
- Requested Service Name
- Requested Service Method
- Response Time
- Response data as XML
- Response Message (If any exception occurs it will logged as Message)
I considered to append two lines to my methods:
// Log Request
Task.Factory.StartNew(() => Logger.Log(RequestParameters.ToXML(),Assembly.GetCallingAssembly().FullName, MethodBase.GetCurrentMethod().Name, DateTime.Now));
// Invoke requested service and get response
// Log Response
Task.Factory.StartNew(() => Logger.Log(Response.ToXML(), DateTime.Now));
I also want to log nested transactions.
Assume a transaction contains a request and a response. A transaction may contains many other internal transactions. When I receive a request, I should register a transaction, and insert a request for it, later, when response received, I should update the transaction response. Please note that I’m trying to store request and response relationship for better tracking.
How can I safely add this logging procedure to methods? I want to restrict developers to implement this logging systems in all methods, some thing like interface or inheritance for method body is required. Can I do this by attributes? Then how?
4
To restrict developers to use the logging mechanism for anything they want, make its visibility only internal. You can then make it available only to your own projects by adding the InternalsVisibleTo
assembly attribute.
To safely and uniformly add the logging mechanism to methods, implement only the functionality in the methods, and wrap the methods in delegates, somewhat like in the following C# like pseudocode:
internal Func<RequestParameters, Response> WrapServiceClientWithLogger(Func<RequestParameters, Response> callService)
{
return requestParameters => {
// Log Request
Task.Factory.StartNew(() => Logger.Log(requestParameters.ToXML(),
Assembly.GetCallingAssembly().FullName, GetMethodName(callService),
DateTime.Now));
var response = callService(requestParameters);
// Log Response
Task.Factory.StartNew(() => Logger.Log(Response.ToXML(), DateTime.Now));
return response;
}
}
This is the hello world scenario for Aspect-Oriented Programming (AOP) and I’m a HUGE fan of it. Your mention/question of using attributes is exactly the implementation detail that is used.
My personal favourite for .NET, though not free (you can roll your own using reflection, and I have, but the performance is comparatively bad) is PostSharp .
Essentially, you have an Attribute that inherits from a PostSharp aspect attribute (eg. OnMethodBoundaryAspect). You would override OnEntry and OnExit to make your async call(s) to trace.
What happens is that PostSharp plugs into compilation and “weaves” the code from your aspect into the IL that gets produced by the compiler, so the performance is roughly identical to what it would be if you had hand-coded it in the method yourself.
Note: I have zero affiliation with postsharp, and have never had the opportunity (ie. budget) to use it in production – sadly. I have used AOP in .NET with success though.
8