XML Strongly Typed Datasets and State Management
On a recent project, of which you may be vaguely aware of if you read my earlier posts, we had great success utilising XML Strongly typed datasets, to help us maintain the clients state, without actually using any of the state management features within .Net.
Many have discouraged use of strongly typed datasets for a variety of reasons, and they certainly have their drawbacks, but I find them extremely useful. Our scenario is as follows :-
The client has a huge amount of information per page, and there are appoximately 10 different pages in the total process of information gathering for this application. It is web based, and at any point in time, a user can close the application, from wherever point they are, and resume the process of information entering, with all previously entered information intact and easily retrievable. Not too different from many apps out there (if a somewhat vague description of our application).
Our approach for state management, consisted of designing a workflow component as an XML Schema (XSD), within Visual Studio.NET and generating a class file from that. This workflow component contained, an application ID, the state of information entry for each stage of the process (ie. had the user entered info for page 1, has page 1 info been validated, has the user entered info for page 2 etc...), client ID, and various other bits and pieces. We used a 'base page' from which all pages inherited from which exposed a property for getting and setting this strongly typed dataset. When the property was set, the strongly typed dataset was serialised to a string and stored in the viewstate of the page, when the property was read, the string was extracted from viewstate, and read into the strongly typed dataset. So all of this information was retained at the client for every single page.
When the workflow was extracted, this provided enough information for us to grab whatever page information was required from the database, as identified by our application ID, the client ID, and populate the relevant page. Sounds simple enough and it worked extremely well. Unknown to us, during testing of this application, the testing team had numerous 'connection dropouts' as they were using a standard ISP over a modem. When the connection was restored, simply refreshing the page allowed the app to resume as if nothing had happened. (Note: Authentication was achieved using Forms Authentication and cookies so the cookie was still valid and thus the user still authenticated to use the site).
Because of the ease and generic method of serialising the workflow to viewstate, we could add properties to the workflow easily within VS.NET designer, and have these available and automatically held at the client without any coding, apart from actually adding the property within the XML/XSD designer.
As a downside, this obviously added weight to the page, however the page weight was heavy due to the amount of information being gathered so this extra weight proved insignificant in the overall scheme of things. The workflow component was in itself not that complex, so some of the complexities/nuances of coding with strongly typed datasets were also not evident.
On the scalabilty front, this also means that a client can hit any web server in a web farm, and further down the path, any app server, and their information is retrieved with all information integrity retained. No use was made of session ID's at all, and in fact, session state were disabled for this application.
This particular method is not for everyone, and simply suited our scenario extremely well, but does serve to highlight a benefit of using strongly typed datasets. Note that this could easily be achieved using a class of your own design without any XML strongly typed fandangled stuff, but its a bit more work, and this proved extremely quick, effective and flexible. This technique could also be extended to encrypt the workflow itself, before being stored within the viewstate for added security if desired.
Again, this probably wont suit everyone, but it may provide enough food for thought to help with you with state management for your next web application.
If you need or are interested in more details, feel free to drop me a line at glav@aspalliance.com