Logging and Tracking Object Activity

Logging and Tracking Object Activity

Old forum URL: forums.lhotka.net/forums/t/3485.aspx


ltgrady posted on Wednesday, September 05, 2007

We have a couple of apps using our brand and project objects.  It's a product database holding product catalog information that is searched and reported on.  That's a very, very over simplified statement about what the app does.

We want to start adding tracking and logging for a lot of our biz functions.  For instance, every time a user submits a search (either on search aspx page, through web service, or some other source) then we want our SearchResults business object to track the critiera, and the products returned.  Every time a user downloads a hi res image from our Search Results page or our Image Vault we want to track the User, the date, the time, the image name.  Etc..

So essentially we want to create some kind of logging/tracking system.  I'm not sure whether to go forward in one of three ways:

1.  Build a Tracking/Logging Biz object.  A very generic object that takes information and saves it into some kind of table that can be retrieved for reporting later.  There would have to be Log Types and several different tables for different kinds of information, but try to use a single Object or service to do the tracking/saivng on info.

2.  Build into my Data Access of existing objects to save to the log tables.  For instance, search would get search results and save those results into log table.  I'm afraid of performance issues here. 

3.  Use some kind of 3rd party or MS block that already does a lot of this work/plumbing.  Something easy to use with good performance and easy to integrate into my CSLA objects.

 

Anyone doing this already, have any suggestions? Thanks, larry

ltgrady replied on Thursday, September 06, 2007

After doing some more reading i'm considering either using the Enterprise Library and referencing it in my CSLA object, or, I've been reading about Service Broker in SQL 2005.  Service Broker sounds interesting, having my CSLA object stored procedures send asynchronous messages that can save my auditing/logging informaiton and not hold up my process at all. 

Anyone used either of these before, anyone have any suggestions or has anyone done anything similar?

SonOfPirate replied on Thursday, September 06, 2007

Not sure that Service Broker would do the job when you want to have logging initiated by user actions.  You'd still need some way to trigger the Service Broker.  But maybe...

Aside from that, I've handled this a couple of ways in this past:

1. Utilize the existing Trace feature.  In this case, I defined a custom SqlTraceListener that interacted with my Log business object to create and store log info in the app's data store.  The benefit of this approach is that the notification system is in place already.  There's no need to wire-up event handers to the various objects (following the good ol' observer patterns) to receive notifications when and what to log.  All you need to do is add Trace.WriteXYZ calls into your code where you want something logged.  Down side is that you have no way to block unexpected things from being logged as any Trace statement will trigger the process.

2. I've also gone the custom Logger-type object route.  That object is responsible for the actual logging part.  It's up to the business objects or other code (such as Command objects) to interact with the Logger and call the WriteToLog method where needed.  The benefit of this is greater control over how it's used.

HTH

 

Professor Rotwang replied on Friday, September 07, 2007

SonOfPirate,
As an aside, for the custom Logger approach, how did you handle the case where the WriteToLog was called via one of the data portal methods? For example, if the log output was a file on the client, then the write would fail if called on the server-side.

I'm also about to start looking into logging activity, not as an audit but just to aid performance and error analysis. The only thing I've come up with so far is having a singleton Logger which would be local to the client, and another one that would be local to the server. The real work would then be in merging the two logs to give a genuine, properly ordered trace of what happened and when.

Sorry if I've hijacked this thread, but it may also be useful for the OP.

Copyright (c) Marimer LLC