DataReader vs. DataSet

In a 4 Guys article entitled Why I Don’t Use DataSets in My ASP.NET Applications and in a blog post, Scott Mitchell discusses the merits of using DataSets to retrieve data in an ASP.net application (or lack thereof). Here’s the gist of it:

Although DataSets provide many useful builtin functions, they add a large amount of overhead (which will increase the more data is retrieved). Check out A Speed Freak’s Guide to Retrieving Data in ADO.NET for more conclusive numbers backing this up. The increase in performance using a DataReader (or SqlDataReader if you are using Sql Server) more than offsets the loss of functionality. So Scott concludes (though many of his other readers disagree).

Personally, I agree. So far I have exclusively used SqlDataReaders in my development efforts. (Though as soon as I start working more with Web Services, XML and Desktop I will probably start to delve in to DataSet-land).

Update: Scott has posted a new article on 4Guys: More On Why I Don’t Use DataSets in My ASP.NET Applications, responding to 60+ comments that were made on the original article. If anything, he is now even more adamant that DataReader is the only way to go.

Don’t Trust ViewState

In this blog post by Scott Mitchell, Scott gives a review of the issues brought up by this article, discussing ways in which a page’s ViewState in ASP.net could be used to compromise a site. ViewState is encrypted by default (unless you set EnableViewStateMac to false, which you shouldn’t need to do). If a ViewState is posted to a page that did not encrypt it, the server will throw an error. However, if a ViewState is posted to the same page (perhaps with different querystring parameter settings), the page may accept the posted VIewState and use its data:

The point is, don’t trust view state (or the data that is put there by Web controls, such as the DataGrid). That is, if you have important information, such as pricing data, it’s OK if it is placed in view state (such as in a row in a DataGrid), but don’t grab the pricing data to charge by just poking around the view state (as in programmatically accessing the contents of a DataGrid). Instead, if you need to get pricing information (or any other important bit of information) for the final order processing, it is imperative that you requery the database.

You have been warned.

MetaBuilders

Site run by Andy Smith featuring lots of cool (and free!) ASP.net controls. Controls that I have used so far include:

  • Default Buttons – Assign a button event to fire when a user clicks enter while inside a textbox
  • Dialog Window – Framework for displaying dialog boxes from within an ASP.net app (and receiving return values from the dialog boxes)
  • Expanding Panel – Panel control extended with Javascript so that it can expand and compress without needing to perform a postback
  • First Focus – Assign a specific control to have focus when a page is first loaded

Definitely worth a visit. Lots of useful stuff here.

Transferring Sessions between ASP and ASP.net

As you will find out by doing some quick googling, there is no automatic way to transfer a session between ASP and ASP.net. Some have suggested that you should load the session variables in a database while in the ASP (or ASP.net) portion of the site and retrieve them into a fresh Session object when you are on the ASP.net (or ASP) portion of the site.

Here is something that looks like a better idea. In this article on EggHead Cafe Peter Bromberg describes a different method that covers four pages, 2 ASP and 2 ASP.net:

  1. Load a Session Object in ASP
  2. Server.Transfer to an ASP page. On this page retrieve each entry in the Session object into a hidden form field. Include one hidden field that contains the final destination aspx page. Automatically post this field to a receiver ASP.net page.
  3. ASP.net receiver page. In Page_Load scan the Request.Form object, insert each posted entry to the (new) ASP.net Session object. Server.Transfer to the destination page (listed in one of the posted fields)
  4. Destination ASP.net page. You now have an ASP.net session object that contains all of the appropriate entries for this user

The same procedure can also be reversed to transfer back from ASP.net to ASP. Sample files can be downloaded here.

Doesn’t look too complicated. I think I may give it a try.