This is a follow-up post to the 2 previous posts that describe how to make a fast and efficient data access layer using SqlDataReader and C#. Here are the 2 previous posts that this relates to:

Data Access Layer using SqlDataReader and C#

Data Access Layer using SqlDataReader and C# - Code Explanation

This is a follow-up to the previous post Data Access Layer using SqlDataReader and C# that describes the details on why and how to set up a Data Access Layer using SqlDataReader. The following is a description of the code involved in wrapping the Category table from the previous post.

First, set up the Utility namespace.

Utility.ColumnDefinition

LINQ is a great new platform but there are two places where it is really weak currently.

1. Its performance is not great. Especially on sites / applications with high performance requirements. You can read more about that here: Performance benchmarks for LINQ vs. SqlDataReader, DataSet - Selects: Part 1.

In my previous post (Performance benchmarks for LINQ vs. SqlDataReader, DataSet - Selects: Part 1 ), I ran queries using LINQ to SQL, SqlDataReader, and Strongly Typed DataSets to see how they compare in the real world. I found that LINQ is much slower than either the SqlDataReader (no surprise there) or the Strongly Typed DataSets (I actually expected the DataSet to run slower).

Links to other posts in this series:
 

I've been wondering about LINQ to SQL performance ever since I started using it a couple of months ago. All I've been hearing from MS is how well tuned the LINQ queries are and how performance is "comparable" to current data access methods. Of course, LINQ has never been billed as the utlra-best performance way to access a database available. What's really powerful about LINQ is the strongly typed objects, language query abilities, and the ease of use.

• Performance benchmarks for LINQ vs. SqlDataReader, DataSet - Selects: Part 1