views:

1430

answers:

4

Hi all,

I have two projects, the DLL project which has all my logic and data access stuff, and the ASP.NET project which does my forms etc.

I am a bit confused. I thought if I added the System.Web namespace reference to the DLL project I would be able to reference the Session state information of the ASP.NET page.

I could use each page to get the session info out and pass it to the DLL for the processing but would love to be able to process things directly from the DLL class(s).

Is this possible?

I have fiddled with the System.Web namespace and just seem able to get a reference to the Session variable.

Thanks all.

Jon

+6  A: 

As long as the Assembly is loaded in the scope of the Session, it will have access.

Although this type of tight coupling isn't really recommended.

Tom Anderson
+1 for not recommended
Larsenal
thank you for the comment about not recommending it. I will go with teh page referencing it and let the DLL just do the logic.
Jon
+3  A: 

You should be able to use HttpContext.Current.Session

Edit

While yes I agree you should not tightly couple your Business Logic DAL or etc assemblies to ASP.Net session. There are plenty of valid cases for accessing HTTP Context outside of a web project.

Web Controls is probally one of the best examples, reusable http modules etc etc...

Now one option if you want to have your DLL pull the stuff from Session is to abstract out session. So you could define an interface like IStorage, that your library will know how to use. Then you can have a SessionStorage or MemoryStorage class and use IoC to inject the appropiate class into your library classes. This gives you the freedom to code it how you wanted it to be coded without tying your code to Session. Oh and one other benefit if done properly can be used to not tie your code to session in the web either.

JoshBerke
Thank you for the info, it answered the question perfectly... but as Tom said I think it is best if I do not tightly couple them. But you hit the nail on the head as far as my question.
Jon
+1  A: 

You can always use HttpContext.Current.Session in your DLL but this is considered as bad practice. A better approach would be to pass the values stored in the session dictionary to your DLL instead of it referencing the session. Another benefit you will gain is that the code in your DLL won't be coupled to the ASP.NET runtime meaning it will be easier to test.

Darin Dimitrov
+1  A: 

As said by the others, you can always use HttpContext.Current.Session in your DLL, I assume it's your BAL, but you need to be really carefull. What if your DLL is later consumed by a windows service, or some other app that doesn't have an HTTPContext? Whenever I've done this it's always been in a property get method where I wrap the attempt to access HttpContext.Current.Session in a try catch block and if anything goes wrong I repull the needed data from the db.