I've inherited an asp.net web solution, which has business logic and data calls as seperate assemblies. In the business 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.
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.