Introduction
One of the major and important topics in the web development core is how to deal with data, how to store it and how to transfer in the web application, its a crucial issue to a degree that the success and the failure of many projects depends on how they deals with data, according to that, state management took a vital place in the web development science and alot of concern was given to this topic in many books, articles and forums.
Background
state management methodologies exists from the moment that HTML invented, at that time there wasn't more than hidden fields to store data in, very simple and page-scope variables, with the time, another functionalities of storing data founded such as query strings and cookies... etc, the foundation of the JavaScript also added more ways to store data.
The state management science was founded from the age of the classic ASP, where something called "Application/Session" was founded, these objects was added to view state, cache and another objects that application uses to store HTTPApplication-scope data to use in multiple pages through the project
Then, the revolutions of the ASP.net comes to the surface, the big-step in the web development became with alot of enhancements and functionalities on the whole .net framework including state management where a comprehensive methodologies of storing data and dealing with them was presented and merged with the old and classic state management functionalities from the time of the classic ASP and HTML, the state management object and methodologies have been varied between client-side and server-side.
Types of State-Management objects
State management objects stores data to be used in the same page, transferred to other page, and to be used in many other pages in the project, with avoiding losing data in postbacks even on local variables of controls, alot of functionalities and methodologies using objects and attributes.
state management objects are splitted into two groups, client-side objects and and server-side objects, client-side objects are page(s)-scope objects that used to keep data in safe from postbacks, or to be transferred between pages, server-side objects are domain-scope objects that are used to store data for the use of the whole application, including business-logic and script language.
There are nine main state management objects, four are server-side objects and five are client-side objects, their use is defined by determining by many factors that I'll discuss it later in this article
Client-Side State Management Objects
|
Server-Side State Management Objects
|
| Cookies |
Application |
| Query Strings |
Cache Objects |
| Hidden Fields |
Session |
| View State |
Database |
| Control State |
|
How Client-Side state-management objects works
Client-Side state management objects are splitted in three categories:
1- URL (Such as Query-Strings)
2- Form (Such as Hidden Fields, view state and control state)
3- HTTP Handlers (Such as cookies)
URL is used to transfer data between two pages through HTTP request and response, while Forms State-Management objects are page-scope objects that are used to save data in the same page to avoid losing it in postbacks and other page actions, where HTTP Handlers state-management objects are domain-scope objects that are used anywhere in the application.
Client-Side objects are so simple, usable and reliable, page-scope and domain-scope objects that are duable through code-behind and scripting language, the only two negative of using client-side state management objects is costs passing data back and forth with server, it means that you are paying the transfer cost of them twice, one when you sends the request to the server, because they will be handled in the HTTP request, and once when the data gets back to the client in the HTTP responce, this means that if you have a big data, huge view state of heavy-weight cookie it will you wait maybe for more than 30 seconds to get the page from a postback.
The second negative of using client-side state-management objects is that you can't ensure that your data is safe, the security in the client-side objects is almost not exists, because of the use of explicit data even in URLs, Query Strings or in Form-Based objects and attributes, any dump user can read and modify any data passed through a query string, it the user was more smarter he could locate the cookie file and gets it's data, if the user knows that there is something in the right-click named "View Source" you can say that all of your cards are burned, because user will get all of the data stored in hidden fields.
The Request Life-Cycle:
When the user enters any URL such as www.codeproject.com, the browser makes a HTTPGet Request for the page on the server that stores it, the server then will response with the HTML page, if the browser was not ever visited this URL before, the server will create a new cookie in the user's PC that contains a unique ID to recognize and track the PC on next visits, and the server may add another data in the cookie, such as Session ID and any data possible. on the next visits the cookie will be sent through HTTPGet Request to the server, the server will get the unique ID in the cookie and then it will show the data that were added in the cookie to the user.
Client-Side objects:
1- Query Strings:
Query strings are used to transfer data through pages, its so simple and easy to use, in addition of it have no weight or cost, its almost weightless in the request & response because it couldn't handle objects of huge data, just raw text... its all that query strings are, and query string are compatible with all browsers and platforms, how life is easy !
Response.Redirect( "SecondPage.aspx?Type=01&Query=Query1" );
The negatives of using query strings are many, it couldnt handle more than text, it means that we cannot transfer objects or controls using query strings, in addition, it couldn't handle huge amount of data.
In addition, query strings are not an appropriate way to transfer sensitive data, such as IDs, names or any valuable data, because query stings appears in the URL at the top of the browser and they are explicitley visible to users, and here is the vital negative, which is users can easily hijack and modify query strings.
Some sites encrypts query strings to ensure data security and to avoid hijacking, such as the query string below:
http:
they encrypts query strings before sending them and then they decrypts them after the other page receives the page.
2- Hidden Fields:
Hidden fields are HTML controls that are used to save the page-scope use data to avoid data from post backs and callbacks, Hidden fields are very usable and reliable, you can save any data you want in them and can retain data from them at any time because of the control state of it, you can either get it's data from code-behind
Hidden fields have a major two negatives which are hidden fields cannot handle objects or controls, it have a maximum size of data. the second negative is that hidden fields are not secure, any user who can access "View Source" can get all data of all hidden fields, because they are not encrypted so they could be visible in the HTML code.
3- View State:
View state is an encrypted data that handles HTML controls data, ASP controls data, and even variables and raw data, in my personal opinion view state is the best client-side state-management object because it's the most secure and the only one who can handle any size of data.
View state is a serialized objects which is encrypted when it is rendered to the user, so even if the user locates the "View Source" he will see just symbols and symbols, data is encrypted fully secured from the hands of the hackers.
View state is encrypted by a 64-bit encoding, so its very hard to decrypt it, the only negative of the view state that it adds about 30% overhead to the page's size, because its encrypted and because its a serialization object, that means it give a big overhead for pages, it maybe not a big problem for pages which does not contain alot of controls or big portions of view state, but it makes a big difference when using it in complex pages and pages which contains alot of controls
View State can handle data from controls and objects, just give "EnableViewState = true" attribute to any control to save it's state, but you should give care to heavy-weght controls before adding this attribute to them (such as DataGrid), because you will make a performance disaster if this control contains a big portions of data, you can touch the difference clearly when trying to access the page from the browser.
here is a page without view state
<html xmlns="%22%22%22%22%22%22%22%22%22http://www.w3.org/1999/xhtml%22%22%22%22%22%22%22%22%22">http://www.w3.org/1999/xhtml">
<head>
<body id="MasterBody" style="margin-left:0; margin-right:0;
margin-bottom:0; margin-top:0; width:98%;">
<form name="aspnetForm" method="post" id="aspnetForm">
form> Here is the data</form>
</body>
</html>
And here is the view state of same page when adding a datagrid with view state = true
<input type="hidden"name="__VIEWSTATE" id="__VIEWSTATE"_value="/wEPDwUJMjAwNTcxODExD2QWAm
YPZBYCAgMPZBYEAgUPDxYCHgRTa2luBQ
tXaW5uWHBPbGl2ZWRkAgcPZBYCZg9kFgRmD2QWAmYPZBYCAgEPZBYUAgMPD2QWBB4Hb25jbGl...bla bla bla"/>
this thing lonely may take from two to ten pages !
objects which we want to view state them should be set as serialized, to be stored in the page, such as the following:
[serializable]public class Person{string fName, lName;float weight;}
public partial class _default : Web.UI.Pages
{
Person p = new Person();
p.fName = "aaa";
p.lName = "bbb";
p.weight = 73.21;
ViewState["MyPerson"] = p;
}
4- Control State
Control state stores data which is stored in the controls, they are as same as view state, but it is dedicated for controls.
5- Cookies
Cookies are files stored in the client PC, this cookie contains a unique ID to let the server recognize the client PC, in addition to any data that want to save it, how cookies work was discusses above.
How to determince which state-management object suitable ?
The type of client state-management object that you want to use is determined by many factors:
1- Importance of the data:
If your data has any degree of importance you cannot use Query Strings neither cookies, because they are very easy to be catched, so if they was highly important and sensitive you cannot use hidden fields too, you should use view state with no regard of the side effect such as overhead.
2- Size of data
If data size was big we should discard objects that pays serialization such as view state and control state, and we should discard query strings too because they are not created to handle big portions of data, if your data was not big to that degree you could use hidden field, or you can use cookies where you can write on it as much as you want.
3- Purpose of using the data:
If the data was used to transfer data between pages we should use query string or cookies, depends on the size of the data, but if data was used in the same page we should use hidden fields, view state or control state, but if we want to use data among the whole application we should use cookies.
