Question

What’s the difference between the two? They seem to have the same functionality at first glance.
Which one has faster performance which one is easier to use?

Answer 1

Using ADO.NET and some kind of SQL:

• advantage: Doesn’t require any sort of configuration or modeling.
• advantage: Is more efficient, as long as you know how to write and optimize SQL. It’s faster to begin with, and is easier to further optimize down the road if necessary.
• requires: more sql knowledge (not bad to have anyway)
• requires: a bit of infrastructure/tooling to cut down on repetitive coding
• argument in favor: If you’re good with sql, have a good data accessing tooling, and are just putting your data somewhere else right away as soon as you get it, there’s nothing compelling about Linq-to-SQL.

Using Linq-to-Sql

• advantage: Can be quite easy to read/understand, even with limited linq experience.
• advantage: Can quickly give you strong types that you can work with right away.
• advantage: You find your errors more often in Visual Studio before or at compile-time. With plain old ado you find you mistakes at run-time.
• requires: setting up the Schema
• requires: knowledge of linq (which you want to have anyway)
• argument in favor: many are finding that Linq performance penalty is not that big, and doesn’t end up being a problem. Further, the sql linq comes up with is sometimes better than what you come up with, even if you fancy yourself a sql pro. (Stackoverflow is a big site, and it’s Linq-to-sql seems to hold up just fine.)

In short, both are pretty good options. Key factors are:

1. Your skillsets: If you’re strong in
   SQL (and code generation), there’s less
   reason to use Linq-to-SQL.
2. You db load challenges: If you don’t have
   to share a puny database server some
   other solutions, and you’re not
   huge, Linq-to-Sql is plenty powerful
   enough.

Being good at SQL will be important for a long time. And, getting good at LINQ is a really good move. Linq-to-XML and Linq-to-Objects are fantastic technologies, and skill with one flavor translates straight to other Linq flavors.