LINQ from a SQL Dev’s perspective

Posted on March 5, 2008


I attended the SQLBits conference on the 1st March and at this event a “developer” (not a SQL Developer I will add) did a quick overview presentation of LINQ; this wasn’t the full session on LINQ that was also presented that day but one of the open mic sessions. He was a very animated chap with a loud Hawaiian shirt but what concerned me (apart from the shirt) was what he said and his view on LINQ.

He presented LINQ as an excellent way to cut corners and query databases and basically said that because Microsoft know what they are doing you can use the T-SQL LINQ it outputs ,  without having to think about coding SQL again. He even went on to to say that you can use the output from LINQ to quickly build stored procedures; copy and paste and there is your database stuff done.

Now, coming from a SQL Developer perspective I was a little shocked at this – not because I thought my job was in jeopardy (“hey, just use LINQ and you wont have to write another line of SQL”) but that people actually might believe the hype around LINQ and other developers might think the same way.

At the end of the day LINQ is great at creating boiler-plate SQL access code;making it easier to get up and running and quickly. A good way to start your model, something you can expand on. However, for pure performance the T-SQL it generates will (currently) not touch what a good SQL Developer can squeeze out of SQL Server. It just couldn’t be used for a high percentage of business applications.

My recommendation is to still use Stored Procedures via LINQ (LINQ does allow you to easily substitute the SELECT, UPDATE , INSERT and DELETE calls for each object with a Stored Procedure) for all but the simplest objects, possibly keeping the boiler-plate LINQ to SQL output for lookup tables or non-critical tables.

What do other developers and SQL Developers think about LINQ?

Posted in: .Net, Article, LINQ