Removing ASP.net Session calls from business logic

I've inherited an asp.net web solution, which has business logic and data calls as seperate assemblies. In the busine开发者_StackOverflowss layer there are a small number of calls to get/set HttpContext session values. I've looked around for an example that will allow me to abstract this away from the business logic as I'd like to be able to reuse these assemblies in non-web projects, could anyone please give me an example of the best way to do this. I was thinking of some sort of session factory that will obtain values from some sort of persistant store depending on the usage scenario but I'm new to architecture really and would appreciate a pointer or two.

The simpliest way in my opinion is to create an ISessionProvider interface, with a Dictionary<string, object> {get; }. Then create a public class HttpSessionProvider : ISessionProvider that returns the actual session bag contents.

At least, instantiate this object in your web app and give it to backend class, either by specifyng it manually or by using any IOC pattern.

[Edit] after a small reflexion, it's not a clean way. You won't have dependency to the asp.net framwork, but you will still have the "asp.net" content of the session accessible. In this case, keep the Interface, but either add specific properties (string customer, int userID, etc.) or return a dictionary only with actual business data

I have done something like this on some projects:

public interface IAppContext {
    string SomeVariable {
        set;
        get;
    }
}
public class HttpContextAppContext : IAppContext {

    public static readonly string CONTEXT_PREFIX = "appcontext_";

    public string SomeVariable {
        set { HttpContext.Current.Session[CONTEXT_PREFIX + "SomeVariable"] = value; }
        get { return (string)HttpContext.Current.Session[CONTEXT_PREFIX + "SomeVariable"]; }
    }
}

What business has the business layer got with Session? To understand that statement a little more, think of it this way: why does the business layer need to persist user related info, ever?

The business layer needs to work with and process user related data, but not store it. This means the data that is currently stored should be injected, i.e. it should be passed in as a parameter to the functions that need it. Doing it this way is forming an architectural contract, it is saying "hey, i need that user info to do my job" in a very explicit way - you are not performing some magic under the hood with some random previously stored values. It is fine for the business layer to authenticate or authorise the user in some way using that data, but it should discard the authentication results after it has finished with them. If the values are being persisted to save a call or two to the database, then you have a problem with the efficiency of your database calls, because database calls for simple things like that are quick.

So my suggestion is to remove any references to Session from your business layer, and change your function signatures to include the user data you need passed.