I’m building UI logging into a long-existing ASP.NET enterprise application. I have my own ideas of how to progress from here and am continuing to research & design. But I’d love to hear some details from the SO community.
Here are the details, assumptions and questions as of right now, subject to evolve within the enterprise as well as whatever input comes in here on SO:
-
Would prefer to have a consistent DB connection since there will be a lot of activity
-
Will probably use the ThreadPool, but will this conflict too much with ASP.NET vying for threads?
-
Possibly use in-memory queue (Queue) for logging batches of inputs periodically? (one per domain)
-
Will need to be configurable. IE: Could log all page events during their normal postback calls, or hook individual control actions or events to being logged whether there’s a postback or not. IE: User collapses a panel.
-
All ‘high-visibility’ UI events that’ll already be posting back as well as other events that won’t necessarilly post back right away. Have a client batch of events and send occasionally?
-
How do we minimize the impact on existing code?
-
Have ‘fly on the wall’ AJAX functionality that posts back accordingly? It’ll basically be watching all that’s been configured to be logged.
-
Logging must be ordered for reporting a user’s step-by-step progress from point A to B in a workflow.
How about a WCF service that does the actual logging, paired with a PostSharp attribute. In your PostSharp attribute you can call asynchronously to you WCF service while your application hums along. I’ve implemented something like this in past projects and it works great with little if no slowing down.
http://www.postsharp.org/