|
This article is based on .Net 2.0 / ASP.Net 2.0
Data passing between Web Pages(ASP.NET) can be done in the following ways:
Web pages are using HTTP protocol and so they are stateless. Web pages are destroyed and recreated with each round trip to the server. Therefore information in the previous page will lose. Also the server doesn’t know whether the requests are all from the same client or from different client. Therefore state management is really an issue in developing web applications. So the developer is responsible for passing, retrieving or storing data. One of the following techniques can be used to maintain the data around the web page.
HttpApplicationState is a great place to store global values or objects.
For example, if you’ve got a fairly static DataSet that is used frequently, you might choose to store it in application state.
Retrieving the object is then as simple as one line of code:
Storing items in application state is nearly as easy as retrieving them. The main difference is that you need to lock the Application object before storing a value, and unlock it when you’re finished. This helps ensure no nasty threading issues muck things up, such as two processes trying to update the value at the same time. Instead, the processes will be queued, if necessary, to avoid deadlocks:
Modifications to objects stored in application state are not persisted automatically back into application state. In other words, if you modify the DataSet or variables after retrieving it from application state, you will probably want to explicitly overwrite the old DataSet in application state with the new one using the code above.
Once an item is added to an item state, it is available to all pages and modules of the application. You can remove an item from an application state by using the Remove method of Application. The following code snippet removes the Title item:
You can also use the Clear or RemoveAll method to remove all items from an application state. The following code snippet removes all items from an application state:
As you might have guessed by the name, the Application object is in scope only for the current Web application. In other words, if you have two ASP.NET Web sites on your server, Application2 will not be able to read values from the Application object of Application1. But all the web pages in the same web application can access the application objects once it is created.
Since the object is storing in the server this method is very secure eventhough the application object will utilize server memory. The application Object will be there until the object is removed explicitly from the application or the application got stopped or crashed.
The HttpCache object is a container useful for storing global variables and objects. At its simplest, the syntax is very similar to using the Application object.
The syntax is very similar to using the Application object, although no locking or unlocking is necessary because thread management is built in to the object.
Cache objects can be removed from server by setting the expiration time or by using the remove method.
The Cache object implements more intelligent storage techniques than the Application object. For example, it will automatically remove seldom-used items from the Cache if memory starts to get low. Luckily, it is possible to optionally specify a priority for each item in the cache — so important items will be more likely to stick around. It is also possible to be informed when an item is removed from the cache using the CacheItemRemovedCallback delegate.
The Cache object allows you to modify how objects are stored in the cache, and for how long. For example, you can specify that a cache item expire after a certain amount of time (Sliding Expiration) or at a specific, fixed time (Absolute Expiration).
The Cache object can also expire items in response to other kinds of events. For example, cache items can be dependent upon a specific file. When the file changes, the related cache item is removed. Cache items can also be dependent upon other cache items. Using this technique, when a parent cache item is removed, any related children are also automatically removed. The CacheDependency object is the key to all of this. There is also a SqlCacheDependency object that can remove an item from the cache whenever specific data in a SQL Server database changes.
The Cache object can be used to create Scheduled Tasks and delayed data display in the web application.
The Cache object’s scope is global to the current Web application. Like Application object, since Cache object is storing in the server this method is very secure even though it will utilize server memory.
Comparing with Application object, Cache object may be automatically removed from the memory if there is a low memory situation.
Session object specializes in storing user-specific items. Every time a new browser hits your ASP.NET application, a new Session object is created for that Web browser. You can store data in the Session object, and it will be available from hit to hit for the same Web browser. Sessions expire after 20 minutes of inactivity by default, although you can change this behavior, as we'll show shortly. By default, ASP.NET uses a cookie containing a unique and random ID that it uses to look up the Session object in the ASP.NET server process.
Adding objects to session.
Session will be removed from server after the specified expiration time on no activity. Also session can be removed explicitly as
The Session object applies to the current Web application only, and also applies only to the current user session. In other words, if two users visit a site that implements the above code, their user names will be stored separately and they’ll never see each other’s user names.
The Session object has scalability problems. Session items are stored in server memory by default. Since session is user specific the total memory used to store the session object is multiplied by the number of users. ASP.NET provides In-Process and Out-of-Process state management. In-Process stores the session in memory on the web server. This requires the a "sticky-server" (or no load-balancing) so that the user is always reconnected to the same web server. Out-of-Process Session state management stores data in an external data source. The external data source may be either a SQL Server or a State Server service.
Since session objects are only dealing with server side processing and storing it is very secure.
Querystring is used as one of the common method of data tranfering between web pages.A “Get” is being performed to pass data along with the URL. In this method data is concatinated with the requested webpage address using "?" and "&" in name value pairs like
In the CitySearch.aspx pages this values can be retrived as
Because QueryString values are visible to the user in the address bar of their browser, they are not secure. Also people can edit the querystring, which may lead into serious problems.
When a user bookmarks a URL into their browser favorites, the full URL (including any QueryString values) is saved and used again the next time the user chooses it from their favorites. This could be a good thing or a bad thing, depending on what values are involved. It can be quite useful for a user to click on a favorite link and resume right where they left off with all relevant data immediately available (since the data was in the QueryString). It can also be a pain to users when a URL they bookmarked doesn’t work anymore, simply because it contains stale QueryString data.
Because the QueryString can only contain text characters it is only useful for storing simple data types. Query string also has a size limitation.
It will consume only very low server memory.
Cookies are very handy in data transferring between web pages. Cookies are a small bit of text (no more than 4096 bytes) that are sent from the server and stored on the client. All relevant cookies are automatically transferred back and forth between the client and server on each page request.
Cookies are in Name value pairs.
Value stored in cookies can be retrived as:
Cookies can be removed by setting a expiration time that is less than current time.
Cookies are browser specific.Also some users don't accept cookies. Also since cookies are stored on the user’s hard drive they are not secure and realiable. Cookies are created per user, per computer. But cookies are low servers resources users.
For moe information read.
An instance of the context object is associated with every page instance. Because a page generally only lives on the server for milliseconds (while being executed and rendered), items stored in the Context object are short lived. In many situations this is the most efficient way to store items because they are quickly and automatically purged from memory. In addition to living for the life of a page, the Context object also stays in memory while transferring to another page. The following code stores an item in Page1 and then retrieves the item in Page2, after which the Context object (and all items it contains) are cleared from server memory.
In page 2 value of UserName can be accessed by
Note that Server.Transfer must be used here for this technique to work. Response.Redirect would fail because that makes a round trip to the client, which kills the instance of the Context object.
This method uses low server memory and it is very secure.
Server.Transfer can be used to access the resources on one pages to access resources on the other page.
The "Server.Transfer" method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
Create the web form with controls that carry values(Page1.aspx).
Create property with Get procedures to return the values in the controls.
Provide some button that posts the Form to another WebForm.
In the button click event handler, call Server.Transfer method that will transfer execution to the specified WebForm.
In the second Form (Page2.aspx), you can get a reference to the first Form instance by using Context.Handler property and cast it to the source WebForm class.
Page1.aspx
Write properties to access the values in the controls inside the source Page class of the page1:
On page1.aspx, button click event, write code:
Then, you will use the Get properties we created to access the control values.
On the Page_Load of the page2, write the following code to access the public properties:
This method is confined to the source and destination page per session.
This method is secure, eventhough it uses more server resouces. The Server.Transfer will shows the URL of the source page even after processing the destination page. This makes harder to debug.
The ViewState object is useful for storing objects between postbacks to the same page. It cannot be used for passing values to other pages.
ViewState items are encoded and output into the generated HTML of the page. If you right click on an ASP.NET-generated Web page in Internet Explorer and choose View Source, you’ll see an HTML element that looks a lot like this:
When the page is posted back to the server, ASP.NET grabs this garbled-looking value and decodes it back into its original state. Be careful, though. Although ViewState values are encoded, they are not encrypted. It may be possible for savvy users to decode ViewState values, so you shouldn’t store sensitive data in ViewState.
You should also try to avoid storing large amounts of data in ViewState as it eats valuable bandwidth on its way to the client and back. Because of such concerns, it is possible to turn off ViewState for pages where it is not needed or wanted. You should keep this in mind when developing controls, because they may not be able to use ViewState if they are hosted on a page that has ViewState turned off. One solution is to use ASP.NET 2.0 ControlState instead of ViewState. ControlState is similar to ViewState but remains on all the time, so it is useful for control development when you need to store critical information between postbacks. It is recommended that ViewState should still be used in control development for storing non-critical values between postbacks.
For moe information read.
A hidden field does not render visibly in the browser, but you can set its properties just as you can with a standard control. When a page is submitted to the server, the content of a hidden field is sent in the HTTP Form collection along with the values of other controls. A hidden field acts as a repository for any page-specific information that you would like to store directly in the page. Hidden field stores a single variable in its value property and must be explicitly added it to the page.
This value can be retrived as
Hidden fields are not displayed on the web browser, but if you view source, you can see both the hidden field and it's value. Not very secure. They do allow you to post information to other pages, or back to the same page.
This method will ncreases the HTML size of the page.We cannot store structured data in hidden fields.
In the days before ASP.NET, posting data was as common as the QueryString (aka “Get”) method for passing data between pages. However, when ASP.NET 1.x came along it was difficult for a page to post data to another page. Instead, the ASP.NET 1.x model ordained that pages should post back only to themselves. ASP.NET 2.0 has freed us from this limitation. The Button control now has a PostbackUrl property that can be used to specify that the form should be posted to a different page. By setting the PostbackUrl property of a button on Page1, the value of a page 1 textbox can be retrieved in page 2 with this code:
You can also use hidden fields to pass around data the same way. This method will user low server resources. But security is low.
The most common data storage is Database using ADO.Net. It is a large topic and so I am not including the details of that in this article.
Storing data in database uses high server resources. It is the most secure, persistent and flexible way for data storing.
|