Question

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

Was it helpful?

Solution

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.

OTHER TIPS

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.

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.

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.

Do not use HttpContext.Current.Session as your dll will not run always with the Web Application. It may run with any other application like Windows,Console itc.

It is better to use a Method which is actully accept a parameter, which will come form Session Value, if you are using ASP.Net Application, otherwise there will not be any dependency of the application. If your dll project already developed and you are trying to modify the exsiting business logic then no, dont modify your exsiting method, use an Overload method.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top