N-tier and STATIC

[Andrea Williams]

I would like to be able to create a singleton when using my Error Handling
object. It uses a static Instance() method to return the currently
activated object. But my question is, since it is static, it is shared
between users on a web site? That I would not like since each user needs to
have their own instance. Does anyone know the behavior of an object that is
create and returned through a static method with ASP.NET? If the Singleton
pattern does make it global to the application, how are other people
handling object instanciation when the object should be shared between tiers
but not between users of the application?

Reference material:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/singletondespatt.asp

 

[John Saunders]

I would like to be able to create a singleton when using my Error Handling
object. It uses a static Instance() method to return the currently
activated object. But my question is, since it is static, it is shared
between users on a web site? That I would not like since each user needs to
have their own instance. Does anyone know the behavior of an object that is
create and returned through a static method with ASP.NET? If the Singleton
pattern does make it global to the application, how are other people
handling object instanciation when the object should be shared between tiers
but not between users of the application?

Reference material:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/singletondespatt.asp

static objects are shared between users. This has nothing to do with whether
or not the object is returned from a static method. It has to do with
whether or not the object is declared static.

If you need something per-user, you need to use Session variables.

You talk about sharing between tiers. Are these tiers meant to be in
separate processes or AppDomains? If so, you will need to use .NET Remoting
to share between AppDomains. Session state won't work.

Does your Error handling object need to maintain state?

 

[Andrea Williams]

The Error object does keep a state, in that it increments a count when an
other error is added to it. It also holds the error messages and exposes
properties to get the Count and Message.

Right now, I'm instantiating the object in my Page Base class. This class
is inherited by all ASP pages. This works pretty well for the pages. But
when I create my business object, I'm passing the Error handling object to
the business layer thru the constructor. I'd like to be able to eliminate
that passing.

Also on my UserControls, I have to expose a property where the page can pass
the error handling object to it. If I forget to do that, then there are
problems, so I'd like to eliminate that as well. I'm not quite caught up on
all of the details in OOP and don't have a firm grasp of the patterns and in
what cases they should be used yet.

Andrea

 

[bruce barker]

you can use the HttpContext.Current.Cache for this. it caches objects for
the life of the request, and will available to any 3 tier objects called
directly from the page.


-- bruce (sqlwork.com)

 

[Hans Kesting]

you can use the HttpContext.Current.Cache for this. it caches objects for
the life of the request, and will available to any 3 tier objects called
directly from the page.

No, as far as I know (and we use it as such), the Cache is application wide,
and the lifetime is not limited to a single request!

But, you can access the Session through HttpContext.Current.Session
(if there IS a current httpcontext, which is not the case on session-end,
for instance)

Hans Kesting

 

[John Saunders]

The Error object does keep a state, in that it increments a count when an
other error is added to it. It also holds the error messages and exposes
properties to get the Count and Message.

You can store the Error object in Session state (e.g., Session["Error"]). It
can be created in Global.asax, in the PreRequestHandlerExecute event, if it
doesn't already exist. Both user controls and pages will be able to
reference it as Session["Error"].

In cases like this, I prefer to create a public property in Global.asax:

public ErrorClass Error
{
get
{
if (Session["Error"] == null)
{
Session["Error"] = new ErrorClass();
}

return (ErrorClass) Session["Error"];
}
}

This can then be referenced as Global.Error.

 

[Andrea Williams]

Thanks for the suggestion, but I forgot to mention that we are staying away
from session state. It's a shared system and we don't want to be forced to
go to a dedicated box.

Any other ideas?

Andrea

The Error object does keep a state, in that it increments a count when an
other error is added to it. It also holds the error messages and exposes
properties to get the Count and Message.

You can store the Error object in Session state (e.g., Session["Error"]). It
can be created in Global.asax, in the PreRequestHandlerExecute event, if it
doesn't already exist. Both user controls and pages will be able to
reference it as Session["Error"].

In cases like this, I prefer to create a public property in Global.asax:

public ErrorClass Error
{
get
{
if (Session["Error"] == null)
{
Session["Error"] = new ErrorClass();
}

return (ErrorClass) Session["Error"];
}
}

This can then be referenced as Global.Error.

 

[John Saunders]

Thanks for the suggestion, but I forgot to mention that we are staying away
from session state. It's a shared system and we don't want to be forced to
go to a dedicated box.

Session state shouldn't force you to a dedicated box. Also, keep in mind
that most of the problems which Session state had in ASP are fixed in
ASP.NET.
--
John Saunders
johnwsaundersiii at hotmail

You can store the Error object in Session state (e.g.,

Session["Error"]).

It
can be created in Global.asax, in the PreRequestHandlerExecute event, if it
doesn't already exist. Both user controls and pages will be able to
reference it as Session["Error"].

In cases like this, I prefer to create a public property in Global.asax:

public ErrorClass Error
{
get
{
if (Session["Error"] == null)
{
Session["Error"] = new ErrorClass();
}

return (ErrorClass) Session["Error"];
}
}

This can then be referenced as Global.Error.