A Re-look at techniques of passing data between pages.

In all of my training session a common question that I faced is that what is the best way to pass data between pages, and mostly the question is asked immediately after I finish my 3 hours of talk and explained everything on "Session Management" in ASP.NET. ahhh!! A tingling effect passes through my entire body as if someone splash cold water on my face. Sounds like after listening to entire "Ramayana" some one asks Who's Shree Ram? ... LOL.....So I thought let me write something which can act as a guidance. Thow you will find many many articles on the subject but I indent my visitors use this as "Quick HandBook"

So Question1: How many ways are there to pass data between pages.

1. HTTP Get - The QueryStrings: One of the first and oldest techniques still used. On the end of the URL address you add "?" symbol and pass key=value pair each separated by "&" symbol. Its like as you pass parameters to a function, here you pass parameters to a URL. What ever you pass is visible to the user in the address bar of their browser .
Plus and Minus:

1. User can bookmark the URL 
2. You can customize page output based on parameters passed
3. Yon can pass 'n' no of parameters
4. You can secure it if your data is sensitive using some scrambling techniques
5. You must also keep your query string within Internet Explorer's 2,083 characters limit.

6. I am not sure which, but some browsers do not support blank spaces eg. http://www.dotnetjini.com?name=Jignesh Desai. you will need to use Server.URLEncode to encode all the characters within the URL as a best practice, after which URL should look like http://www.dotnetjini.com?name=Jignesh%20Desai.

2. HTTP Post technique: With size limit of querystring POST is the preferred method for sending lengthy form data. when a form is submitted user does not see the form data that was sent to calling page.
Plus and Minus:

1. You can post virtually unlimited data
2. Binary data(Uploading of file) can be passed using POST technique only.
3. Data is secure as its not visible to users as in QueryString technique.
4. If you wish to send any additional information you can use HTML <Hidden> field to pass it along with other data.
5. In contrast to HTTP GET technique POST request sends additional data to the web server in HTTP Headers
   

3. Cookies: Allows you to store bit of information not more then 4096 bytes on users computer. Browser does read/write of cookies on users computer. Cookies are temporary in nature unless you specify expiry datetime after which it expires automatically (Client-side persistence cookies). They are often used by browsers to maintain a Session ID (SID). [More Info...]
Plus and Minus:

1. Smart users can tamper data stored in cookies so avoid storing sensitive data.
2. Remember each time you access server browser will sent relevant cookies.
3. Can be used to store username and password so that next time user can AutoLogin, so called "Remember Me" feature. Ensure you encrypt such data rather then storing as simple text.
4. Specifying the domain name to indicate the end of the domain for which the cookie is valid.
5. Use Cookies only when your website should execute using specific setting from that particular computer.
   

4. Database: Good thinking if you want to audit information for each user. Normally used to understand behavioral pattern of users & visitors. You will need to periodically delete the data after you have abstracted information you need.
Plus and Minus:

1. Too much of database operation will impact sites performance.
   

5. Application / Cache: Used to store global data accessible to all users. Object "Application" is there from ASP days, where as a similar object "Cache" with add capabilities was introduced in ASP.NET.
Plus and Minus:

1. Data is stored on server side.
2. Its important to plan what data is needed to store since it occupying server's memory.
3. .NET out-of-box offers you to choose to store these data either in server's memory(Default) or A dedicated machine or A SQL Server Database, all done by a simple XML based configuration(Web.Config), which means you can change your storage technique on fly.
4. Choose Application or Cache when you are sure that data stored will not be updated so frequently.
5. Must call lock() and unlock() before modifying Application object. This is not need for Cache objects.
6. Cache object is similar to application but has added features like expiry policy(Sliding Expiration, Absolute Expiration, dependency based Expiration, dependency can be a file, other similar objects or SQLServer Table)
7. Can be used to securely store "ConnectionString" instead of Web.config file where it is stored as plain text.
8. Another example can be Shopping cart data which is same for all users and likely to change once in a month or week.
9. Since Cache object can expire automatically always check if CacheObject is not null before accessing values stored in it.
10. Lookout for global.asax for Application Start and End events, Ideal place to declare and initiate objects.
11. Be Sure if you are storing objects, they are serializable.
12. Cache object uses some intelligent techniques for memory management, objects are automatically flush out of memory if it starts to get low or object not frequently used. Change Cache.EffectivePercentagePhysicalMemoryLimit to specify percentage of physical memory that can be consumed by an application before ASP.NET starts removing items from the cache.
13. Before you add more items into Cache, you can check for Cache.EffectivePrivateBytesLimit property which returns the number of bytes that can be used by the application process.
    

6. Session: Session objects are used to store user specific data. Every user session gets a unique session ID generated by Web Server. Server creates a new Session object for each new user, and destroys the Session object when the session expires.
Plus and Minus:

1. Like Application and Cache Its important to plan what data is needed to store in Session objects since it occupying server's memory.
2. Its also important to plan because Session objects can consume up resources faster as no of visitors increases.
3. .NET out-of-box offers you to choose to store these data either in server's memory(Default) or A dedicated machine or A SQL Server Database, all done by a simple XML based configuration(Web.Config), which means you can change your storage technique on fly.
4. Be Sure if you are storing objects, they are serializable
5. Lookout for global.asax for Session Start and End events, Ideal place to declare and initiate objects.
6. SessionID is stored in cookies which is passed back to server on each request. if browser has disabled cookies due to security reasons you can still manage sessions by altering web.config setting eg <sessionState cookieless="true"></sessionState>
7. Configure Session.Timeout as per your need, default is "20" minutes. which is ideal in most scenarios.

7. ViewStates: The ViewState object is useful for storing and remembering data between postbacks to the same page. It cannot be used for passing values to other pages.
Plus and Minus:

1. Can be used  to remember sorting order between postbacks
2. ViewState does not user server resources as data is stored within the page itself under a hidden variable "__VIEWSTATE" and passed to server and back on each request until the user is on the same .aspx page.
3. Not advised to store sensitive data as its not encrypted.
4. Not advised to store large amount of data as its going to consume internet bandwidth impacting page performance.
5. Control ViewState by setting it to "off" for either control or page when not required.

8. HttpContext Object: Lesser known but HttpContext is associated with the current request. The Items property on this object is a collection that you can use to pass things around for the currently executing request *only*.  Can say its similar to POST but in a secure way. eg.

Context.Items("DiscountChoice") = txtDiscountChoice.Text 'On Page1
Server.Transfer("CalculateBill.aspx") 'On Page1
Dim s As String = Context.Items("DiscountChoice").ToString 'On Page2

The static property Current of the HttpContext class can be useful whenever you want to grab the HTTP object from your custom class eg.

Class MyClass
Public Sub MySubRoutine
   HttpContext.Current.Response.Write("I can output HTML from my Custom Class Also.");
End Sub
End Class

Summary