Are ADO.NET Datasets dead?

If you are plugged in at all to the Microsoft world you have been seeing more and more LINQ and ADO.NET Entity Framework buzz.  You can't go to a conference or attend a User Group meeting without discussing one of these new data access technologies.  I'm not saying that's a bad thing... Unless you are a Dataset, Datatable or Dataview.

I wrote a post back in May trying to shed some light on when to use which technology.  You might want to read that post and the comments before reading on.  In that post I stated that if you are creating new applications or just adding on features to your current app I would use LINQ or EF instead of ADO Datasets.  There are many reasons.  Here are the most compelling reasons to use LINQ and EF.

  • Objects - The nicest thing about LINQ and EF is they provide some of the foundations for Object Oriented programming.  They literally force you to think and work in terms of objects and collections of objects instead of rows and tables of rows.  By setting up this foundation, these technology allow for the application to grow and use some of the more complex OO concepts without doing tons of work to fill and save objects from Datasets.  So, start simple and as the requirements on your application change you can use some more complex OO topics to solve those problems.
  • Memory - There are two schools of though on this topic.  Some people like to pull all the data back into memory and then work with it there.  Others don't like to fill memory with data that might not ever be used.  LINQ and EF allow for both.  When you build your LINQ and EF models you can use stored procedures same as you used to with Datasets and bring back the whole table if you desire.  Or you can use the LINQ syntax to do filtering and sorting, which uses the power of the relational database engine to get only the row(s) you need.  To me it is compelling to have the flexibility that LINQ and EF give me.
  • Performance - We can go round and round about the performance implications here.  People say stored procedures are faster because they are pre-compiled, but with the new technologies these LINQ queries are cached and optimized and the difference is often minimal.  To me this is the 80\20 rule.  80 percent of my queries will run the same or faster in LINQ and EF than they do in a SP.  The other 20 percent of my queries will run faster in stored procedures.  So, use both.  LINQ and EF allow for using SP or the LINQ syntax.  Plus, with LINQ you can bring back only the columns you need which can improve performance as well.  I'm not saying quit using stored procedures, but instead of just blindly using them because that's what you've always done, step back and analyze your requirements to see if it's worth it. 
  • Interop with Other Object Collections - The other benefit of working with LINQ and EF is that you can join your data objects with other object collections.  If you've seen my talk on LINQ and the demo related to joining my SQL data with file data retrieved using the System.IO objects.  It is so easy and would require lots of work with Datasets.

There are many more reasons out there, but these are a few of the ones that are most important to me.  Any one else want to add?

The Most Popular Computer Languages

This is a shout out to all my VB readers out there.  First check out this article on the most popular languages.  At first I was surprised to find that C# is number 8 and VB is number 4.  However, it looks like they are grouping all versions of VB into the same category.  This makes more sense since VB has been around for way longer than C#. 

I love sitting around with some of the old timers talking about when they used to use punch cards to program.  To me VB is that legacy.  One day I'll be sitting around with some young whipper snapper right out of college saying:

"I remember back when I used VB 3 and I had to choose the option of creating a 16 bit or 32 bit application when creating a new project."

Today, VB.NET is a powerful Object Oriented language and is used in some of the most advanced software packages out there.  I just remember the days when it wasn't....

LONG LIVE Visual Basic!

Useful Design Patterns

I'd like to thank the Northern Colorado .NET User Group for giving me the opportunity to speak to their group last night.  We had a good discussion about Design Patterns.  The patterns we discussed were Singleton, Command, State, Strategy, Provider, Plug-In and Module.  Although my demos are pretty simple and cut some corners, I think you can get a good idea of how to use these in your applications.  The take away from the discussion was that these patterns are great and provide some great guidelines, but they may need to be modified slightly to fit the problem you are trying to solve.  The 2 keys are to always code to an interface or base class and try to use aggregation in place of long complicate inheritance trees.  Again it was a great talk and I hope everyone in the group learned something.  I know I did.

Below is a zip that contains the slides, which explain these patterns, and all the demos.  There is also a DB script for SQL Server to create my sample DB.  The only change you need to make is the connection string for the DB.  Enjoy!

UsefulDesignPatterns.zip

Returning XML from an ASPX page

Today I needed to make an ASPX page return a simple XML document with some basic server information.  The example below is over simplified but I think you can get the point.  This is pretty easy as it turns out.  Here are the steps:

  1. Create a new ASPX page in your solution just like you would any other page.
  2. Next remove everything from the markup except the @Page tag.  It should look like this an have nothing more:

 

  1. Here is a code snippet of the page load event that returns a simple XML element:

That's it.  I also found a nice post here that shows how to read XML from file and stream it back through the browser.  Pretty simple and useful.