views:

133

answers:

3

Every stored procedure we write has to have clientip, serverip, windows username, etc passed on to it.

The question is how do I efficiently pass these to DAL?

A: 

You should have all of the above data accessible either in the System.Environment class, or in your own Thread Principal of some kind. Your DAL can easily pull in from both or either of those sources.

GWLlosa
A: 

Create a class to hold this data, a factory to build it and helper methods to consume it.

IUserContext
{
int param1 {get;set;}
int param2 {get;set;}

SqlParameter[] GetSqlParameters();
}

UserContext : IUserContext{}

UserContextFactory
{
    internal IUserContext IUserContextFromRequest(){}
}

Good luck

Ben
Similar to what I was suggesting. Basically, take the class Ben's recommending, and make it implement IPrincipal. Then you can store it in the thread and not worry about updating it.
GWLlosa
what do you mean by storing it in the thread?
gnomixa
I only have one thread in this app (its a web app with no multi threading). if I use the approach above (which I like), would this be persistent btwn postbacks?
gnomixa
Could someone explain clearly how you would use this class inside a real application? From what I understand, the way to use it would be to make it static. But then, I might as well use Global.asax. Am I missing something here?
gnomixa
I like using a custom principal and identity, but this seems like more information that I would keep there. To me, each request should be logged one time with this information and then subsequent queries only require the user/session id as a parameter.
Ben
As far as multi-threading goes, a web application is multi-threaded. A single request is a single thread, but five concurrent requests would be five threads. Storing the principal on the thread would only last for the life of the current request.
Ben
+1  A: 

I'm assuming this is a web app in ASP.NET. If that's the case, you have access to all these things in the context of a web request outside of the web application through the following static instance:

System.Web.HttpContext.Current

If everything you need is standard stuff that you usually have in the Request, Response, and User objects that are available by default at the Page level, then this should be all you need. If you need information that is custom to your web app, then Ben's answer (above) should work.

Rich