O
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.
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.)
(excited!!!), and have gone head first into writing my first
application.
Sadly, I've hit a design barrier.
upon deploying an application - similar to servlets. I don't reallyFrom what I can see, ASP.NET 2.0 has no facility that is instantiated
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.)