Chapter 15. LINQ to SQL and ADO.NET Entity Framework

 

Bob Beauchemin

In ADO.NET 3.5 and 3.5 SP1, Microsoft introduced two models designed to abstract SQL statements into a high-level language and to operate on database data as objects. The first, LINQ to SQL, is a lightweight mapping of LINQ (Language Integrated Query) calls to the SQL Server database. The other model, ADO.NET Entity Framework (EF), consists of an object-relational mapping (ORM) framework as well as query and view services built over the ADO.NET provider model. The Entity Framework has its own dialect of SQL (Entity SQL or ESQL) and can use ESQL statements or LINQ queries to access data. Although neither framework uses vanilla T-SQL as its query language, both frameworks can generate SQL statements or use existing stored procedures to access the database. This chapter is not an introduction to these frameworks as I assume that you already know their basics, but I will discuss how these frameworks interact with SQL Server, especially with respect to performance.

One way to look at the performance of an abstraction layer is to examine and profile the ADO.NET code, but both EF and LINQ to SQL are T-SQL code generators (EF is not database-specific, but I’m only talking about SQL Server here); therefore, another way to address performance is to examine the generated T-SQL code. I will look at performance from the generated T-SQL code perspective.

LINQ to SQL and performance

Generating SQL that uses projection

Updating in the middle tier

Optimizing the number of database round trips

LINQ to SQL and stored procedures

Tuning and LINQ to SQL queries

Summary

About the author