Entity Framework is one of my Micrsoft's new recommended ways to build a data access layer. It provides a lot of flexibility in allowing you to control your database model, easily update your model, and automatically generates a wrapper on your database model so that you can access all of your tables as objects (called Entities).

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

If you've attempted to create your own Data Access Layer for LINQ and want to use the built-in data binding for .NET controls like a GridView, you know the nightmare of trying to get these controls to work together with LINQ new IQueryable interface. After much pain and suffering, I was able to cobble together little tidbits from various posts to create a solid object that can be used as a "codeless" ObjectDataSource for any GridView AND support sorting, paging, and filtering just like if you were to databind to a LINQ to SQL object (like EVERY tutorial shows you how to do).