Comparing state management tools
Ημερομηνία: 20/01/2013
Δεν έχετε συμπληρώσει όλα τα απαιτούμενα στοιχεία
Το email που δώσατε δεν είναι σωστό
Across the latest articles we've encountered many state management tools. View state, session, cookies, query string, cache, and application state have all been thoroughly explored. This article contains a direct comparison of these techniques, helping the reader choose which one to use depending on the circumstance.
The basic differences between these technologies, stand on the following questions:
-
Who can use stored data?
-
Where and for how long is the data stored?
-
Is information safely stored?
-
In what way excess usage can cause problems?
-
What type of info can be stored?
These questions can group into two major categories.
-
Data stored in the client. It is not safely stored and increases bandwidth.
-
Data stored on the server. It is safely stored and consumes server resources.
Based on what we've said so far, we're about to go through all tools, one by one.
View state
Even though view state is automatically used by ASP.NET, developers will not use much of view state as it can store values in between postbacks of a single page only. So, in case you need to transfer data through pages, view state will be no good. However view state is the only method that can store info for each copy of a page, since data is stored within the page's HTML. By default, the values are not encoded, but this can be easily changed, so security is not much of a problem. Data will remain stored until the page is closed. Excess usage will result in large HTML page which will make it slow to transfer.
So, view state is not a bad thing to use, as long as you need to store values that will be used within one page.
Cookies
A cookie will be stored in the user's browser and will remain there until it is expired. Cookies can be seen by an eavesdropper or changed by the user; therefore it should contain non sensitive data, unless properly encrypted. Cookies can store information concerning user's choices and preferences. What is the language he prefers? What is his favorite category? And so on. When the user answers such a question for the first time, he need not be asked a second time. Unfortunately, cookies cannot hold much of an info and can only be stored in string form. There may also be users who wish to turn off cookies in their browser.
Cookies and view state are both stored in the client.
Query string
Query string is highly popular as it is the only way, you can copy values stored, by copying the page's url, since info is stored in the url itself. Since everyone can see the url, it is quite unsafe. Yet, this is the reason for storing values in a url; so that it can be easily shared. Values stored in the query string have to be strings and are usually small in size, but most times this is not a problem. Query string is mostly used so the client can search a website, moving around from one category, or one product, to another.
Session
Session is the perfect tool to store sensitive values, unique for each user. Since it is stored in the server it is quite safe (with the exception of the session ID which is stored within a cookie). Session contains a timeout attribute which is refreshed whenever the value is requested. All types of info can be stored in session, however since each user holds its own session, if not taken into account, session memory can be easily increased and slow down the server. Session can be used to store information concerning an e-shop cart or a sign up procedure containing more than one step.
So far, these methods, create unique memory allocation for each user. The remaining two, are the same for all and can be viewed by all users.
Cache
Caching can be used to store any type of value for as long as we want. It is perfectly safe as it is stored directly in the server. As output caching, it can store a full page or control. As data caching, it is mostly used to store info retrieved from the database, so it will save us from hitting it again the next time. If used improperly, cache may exceed its memory limit, in which case, values with the least priority will be removed first.
Application state
Application state is similar to caching since it uses server side storage than can be viewed by all users. However it is not much used since it is less flexible than cache. Yet, values stored in application state will not be removed as long as the application exists.
Conclusion
I tried to gather all of the state management tools in one place, so their distinction can be made plain to the reader. All techniques can be used, and will be most useful when the circumstances are appropriate. A developer will have to ask himself the questions stated above, in order to choose which one is the best to use.
Πίσω στο BlogΠροηγούμενοΕπόμενο