Microsoft's .NET platform has an amazingly performant and extremely useful class called Trace. I use this every time, I need to find some piece of information in the application for debugging/diagnosis purpose. Good thing is that you can leave the statements and have Trace turned off through configuration without worrying too much about its impact on the performance of the application.
Unfortunate part is that .NET framework still leaves you with a lot of work to do for basic TraceIn/TraceOut type of functionality. Either you end up wrapping your implementations through some known patterns like Decorator pattern or you end up making your classes have a complex class hierarchy where implementations are controlled through Base class. There are third party tools like PostSharp available in the market which let you implement this elegantly through AspectAttribute which essentially rewrites your IL code by adding the plumbing code that you would have added manually otherwise. While it is good, it seems a little intrusive to me because it makes your test cases dependent on the "additional rewritten" code and forces you to wade through that to test the actual code.
This brings me to a question - shouldn't .NET framework provide TraceIn/TraceOut functionality by default? I would suggest that it should be in-built and it should let users configure it through configuration file - much like IIS logs. Yes, there would be related security concerns but I am sure there must be clever ways to take care of that too.
Just a thought.
No comments:
Post a Comment