It seems to me, as a developer who came up through web-based scripting technologies, that we got jipped with ASP.NET due to the statelesness of HTTP. This sounds like a very novice statement, since this limitation has nothing to do with ASP.NET What I mean by this, is that in any other .NET app, be it WinForms or console apps, you can instantiate objects all you want, and reference them with no problem whatsoever. Where this falls apart is in web applications for reasons just mentioned.
This becomes a problem when working with classes and objects in ASP.NET for which state is essential. There are several traditional approaches to state management, including client side cookies, querystring parameters posted to the address bar, the Session object (much more OK to use in ASP.NET than Classic ASP), System.Web.Caching, and then of course, the red-headed step child of them all- the application cache. I won't get into why application cache has become to be so frowned upon other than to say that it was abused back in the Classic ASP days. Today, there is no harm in using it (correctly), but it seems to have fallen out of favor. Personally, I think the application object is a very suitable mechanism for state management at the application level, and the events provided within the Global.asax make it quite useful.
But, I digess.
What about a “home-brewed“ option for keeping state? In ASP.NET, objects are created within various events in the page execution lifecycle. Each event provides an opportunity to manipulate an object or set of objects at precisely orchestrated times before its too late.
When is it too late? After the page has loaded and rendering of controls is complete. After this point, the web server has no clue what objects your page references. It doesn't care, because as far as its concerned, it's job is done.
Aside from the web being stateless, the biggest limitation is due to the thin nature of our clients (browsers). They are disconnected from the wire and don't have the ability to maintain a reference to a stateful object. So these objects that we create and dispose of end up somewhere in the CLR cosmos awaiting garbage collection.
So what do we do if we need to persists some objects so that they are available on the next refresh or postback? What if we need to store frequently used information, either to improve performance (caching) or for some other business requirement?
Not much you can do, save for popping it into the cache or a session variable. Writing it to disk in a cookie. Maybe you base64 encode it and push it into viewstate. These are all options we've covered for persisting state in web applications.
What about web services? Web services are architecturally very similar to web applications. They too rely on HTTP and are therefore, stateless.
A collegue of mine recently demo'd a caching mechanism he created for a web service which does not rely on any of the state management tools we've talked about thus far. The web service makes calls into a business services layer which resides in its own class library.The methods within this business services layer in turn make calls into a data access component which resides in a seperate library representing the data access layer. Pretty straightforward n-tier stuff.
Of greatest significance is that the classes/objects within these layers are completely decoupled from the web service. So, in a sense, the web service is an HTTP client that calls into the business component. While the web service has not way to (automatically) keep track of the objects that it creates (by calling into the business layer, for example), the class does. How you ask? By using a static property linked to a collection or any other structure that you wish. In this way, a customized repository can be created.
Granted, this method of state management is extremely volatile, but it makes for one slick home-grown caching mechanism. And, there's absolutely no reason the same approach can't be taken with ASP.NET (web) applications. Only question I have is why didn't I think of this earlier?
I put this technique to work in this sample solution that demonstrates this approach. Essentially, you add a name to a collection of name objects in an arraylist. You can clear the form, navigate away from it, close your browser, and when you come back to the page and click 'View Contents', the name collection is pulled from this home-grown cache!
Download Solution: CachingWithStaticProps.zip