If anyone ever looks at your log, except for debugging, I'll be surprised.
I'll be even more surprised if they get any value out of it.
The exact calling sequence down to your DB layer (please stop saying "file")
is likely to change over the course of time. Many of the changes will not be
changing the semantic reason why your DB layer was called. I hope that's
what you mean to capture by capturing the name of the calling class. BTW, I
hope you intended to capture the name of the calling method as well.
Example: today, my Employee class has a method UpdateHoursWorked which calls
the DB layer to write the updated hours to the database. Tomorrow I may
perform the exact same function by having a Timeclock class update the hours
to the database. There is no semantic difference between these two, yet
you'll be capturing different information. Good luck in making any use of
that.
You'd be better off changing all of the classes which call your DB layer to
somehow provide the DB layer with the semantics of what they are doing. The
DB layer could then log that. This could be done via a separate parameter,
or via CallContext, but the callers shouldn't care about that. Just add a
static SetSemantics method to your DB layer and let it decide how to store
the information.
--
John Saunders
John.Saunders at SurfControl.com
"Hmnt" <Sa*********@hotmail.com> wrote in message
news:D6**********************************@microsof t.com...
Well,
U leave me no choice but to explain the details--
Here I've to maintain a 'Log' of the classes which used the functionality
of this central-class(actually its my DB-layer file - so i need to track which
class executed which DB -object-[Stored Proc, INS/UPD/DEL...etc.]
Its really pathetic to send the caller name as a string argument (and even
i can't change ALL the functions already implemented !!!)
Hope u understand my prob n fin me a relevent solution ...
