Preserving data within a whole application.

[Omega]

I just recently recieved my full copy of Visual Studio 2005
(excited!!!), and have gone head first into writing my first
application.

Sadly, I've hit a design barrier.

From what I can see, ASP.NET 2.0 has no facility that is instantiated

upon deploying an application - similar to servlets. I don't really
need the functionality of a servlet, but what I am interested in
getting is an "always on" class that exists between different requests
between different ASP.NET classes.

My first instinct is to create some static monster class that has all
my functionality and that will persist for the duration of the whole
ASP.NET application's life. Although something in my gut tells me that
static classes are not to be abused in such a way.

Does ASP.NET provide me with anything that I can use to share
information between aspx pages and web service classes? On top of
that, what would be the best way to write a totally non-visual class
that is responsible solely for my "business logic"? The idea is that
after writing this omnipresent workhorse class, I'll use aspx pages,
web service pages and anything else to make use of the same set of data
without having to hit a database for small tidbits of session data.

(I'm writing a very simple user login system, and while I'm aware of
ASP.NET's built in user handling, I would like to write my own system
and then work it into ASP.NET's system afterwards.)

[Teemu Keiski]

You aren't actually looking for servlet functionality but application level
state? Cache or Application could help with that

--
Teemu Keiski
ASP.NET MVP, AspInsider
Finland, EU
http://blogs.aspadvice.com/joteke
"Omega" <at******@gmail.com> wrote in message
news:11*********************@y43g2000cwc.googlegro ups.com...

I just recently recieved my full copy of Visual Studio 2005
(excited!!!), and have gone head first into writing my first
application.

Sadly, I've hit a design barrier.

From what I can see, ASP.NET 2.0 has no facility that is instantiated

upon deploying an application - similar to servlets. I don't really
need the functionality of a servlet, but what I am interested in
getting is an "always on" class that exists between different requests
between different ASP.NET classes.

My first instinct is to create some static monster class that has all
my functionality and that will persist for the duration of the whole
ASP.NET application's life. Although something in my gut tells me that
static classes are not to be abused in such a way.

Does ASP.NET provide me with anything that I can use to share
information between aspx pages and web service classes? On top of
that, what would be the best way to write a totally non-visual class
that is responsible solely for my "business logic"? The idea is that
after writing this omnipresent workhorse class, I'll use aspx pages,
web service pages and anything else to make use of the same set of data
without having to hit a database for small tidbits of session data.

(I'm writing a very simple user login system, and while I'm aware of
ASP.NET's built in user handling, I would like to write my own system
and then work it into ASP.NET's system afterwards.)

[Omega]

Neato, how would I go about making use of that?

Where in my application can I have my workhorse class instantiated
before any requests are made? Should I just write a singleton that
stores it's reference in the cache or Application?

Keep in mind, I want this object to exist for every page and web
service in my program. It must exist across page loads, across page
types and across users. I want all that information to be preserved
even after the page has been rendered and sent out to the user.

[Teemu Keiski]

That is Application or Cache, both are application wide. Difference is that
Cache supports all sorts of dependencies where cached data can be stalled
when for example a file or other cache item, (in ASP.NEt v2 also data in
database) changes while Application is just static. You could initialize
them in global.asax in Application_Start event which runs once when app
starts. Or you could do it in lazy way when first request for the data comes
in. It's up to you.

On Page you have Cache and Application properties available as is. Like

Application["key"] = obj;
object obj = Application["key"];

//And same with cache plus a few overloads of Insert method

In web service you access cache with Context.Cache or just HttpRuntime.Cache
(Application is as-is). In case you want to be sure about accessing even
without request context you could use HttpRuntime.Cache

--
Teemu Keiski
ASP.NET MVP, AspInsider
Finland, EU
http://blogs.aspadvice.com/joteke

"Omega" <at******@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...

Neato, how would I go about making use of that?

Where in my application can I have my workhorse class instantiated
before any requests are made? Should I just write a singleton that
stores it's reference in the cache or Application?

Keep in mind, I want this object to exist for every page and web
service in my program. It must exist across page loads, across page
types and across users. I want all that information to be preserved
even after the page has been rendered and sent out to the user.

[Omega]

You Finnish folk rock my small Canadian world. One of my favourite all
time teachers from high school is a Finnish dude.

Thank you so much for the help!