Reference To An Instantiating Obect

[Microsoft Newsserver]

I am instantiating an object in an ASP.NET page. From this object I want to
be able to access Session. I dont want to change the constructor to pass the
page reference to it, and I dont want to have to add extra properties.

How can I get a reference to the page object in which the object is
instantiated.

Cheers

 

[Jon Skeet [C# MVP]]

I am instantiating an object in an ASP.NET page. From this object I want to
be able to access Session. I dont want to change the constructor to pass the
page reference to it, and I dont want to have to add extra properties.

How can I get a reference to the page object in which the object is
instantiated.

Why would you believe there's a way to do this? Objects don't have the
notion of a "creator". You need to tell them about objects.

It's possible that there's some thread-static way to get to the
"current page" via HttpContext.Current.Request or something similar...
but there's no general solution.

If you want to give access to the reference, why don't you want to
change the constructor? You're really trying to add state without
adding state...

 

[Jesse Houwing]

Hello Microsoft,

I am instantiating an object in an ASP.NET page. From this object I
want to be able to access Session. I dont want to change the
constructor to pass the page reference to it, and I dont want to have
to add extra properties.

How can I get a reference to the page object in which the object is
instantiated.

You can use the HttpContext.Current static variable. You can access both
the current page and the session from there.

 

[Microsoft Newsserver]

Why would you believe there's a way to do this? Objects don't have the
notion of a "creator". You need to tell them about objects.

Answer.
It was a question. I was wondering if there was a way do do this using
reflection or some other method.
A simple yes or no would have sufficed.

It's possible that there's some thread-static way to get to the
"current page" via HttpContext.Current.Request or something similar...
but there's no general solution.

Answer.
Actually, I had forgotten about the system.web namespace which I added
as a reference and then was able to acheive this.

If you want to give access to the reference, why don't you want to
change the constructor? You're really trying to add state without
adding state...

No comment.

 

[Microsoft Newsserver]

Thanks for your help.

I added the system.web namspace and used it. I had forgotten about that
facility.

 

[Cowboy \(Gregory A. Beamer\)]

Yes, you can do this, as Jesse has mentioned, by working through current
context.

There is also a good reason why this, as a rule, is not a good idea. You are
tightly coupling your class (or class library) to a web application. This
does a couple of things:

1. Makes it difficult, if not impossible, to unit test using unit testing
frameworks, as you have forced a dependency that cannot easily be injected,
if at all

2. Forces a complete redesign of your application if you ever move to
another type of library (web service, smart client, etc.)

You are best advised to grab the info you need off the page before you fire
off the library, as this leaves no circular dependencies.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************

 

[Arne Vajhøj]

You can use the HttpContext.Current static variable. You can access both
the current page and the session from there.

The class will only work in web context then.

I would try and avoid that type of coupling.

Arne

 

[Microsoft Newsserver]

Point noted. - Thanks

Yes, you can do this, as Jesse has mentioned, by working through current
context.

There is also a good reason why this, as a rule, is not a good idea. You
are tightly coupling your class (or class library) to a web application.
This does a couple of things:

1. Makes it difficult, if not impossible, to unit test using unit testing
frameworks, as you have forced a dependency that cannot easily be
injected, if at all

2. Forces a complete redesign of your application if you ever move to
another type of library (web service, smart client, etc.)

You are best advised to grab the info you need off the page before you
fire off the library, as this leaves no circular dependencies.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box! |
*************************************************

 

[Jesse Houwing]

Hello Arne,

The class will only work in web context then.

I would try and avoid that type of coupling.

You could check

If (HttpContext.Current != null)
{
// In web context
}
else
{
// other
}

Either way, if you need the Session or elements on the page in the class,
you're coupled any way.

 

[Arne Vajhøj]

You could check

If (HttpContext.Current != null)
{
// In web context
}
else
{
// other
}

Either way, if you need the Session or elements on the page in the
class, you're coupled any way.

Yes.

The problem is not the answer but the question.

Arne

 

[Jesse Houwing]

Hello Arne,

Yes.

The problem is not the answer but the question.

Yes, but that also depends on what the class must do. If it's specialised
in formattign or chackign controls on the page, then this is a completely
logocal thing to do...

 

[Arne Vajhøj]

Yes, but that also depends on what the class must do. If it's
specialised in formattign or chackign controls on the page, then this is
a completely logocal thing to do...

But making the Session or whatever being transferred as an argument
instead of grabbed via .Current would make the dependency explicit.

Arne