"Paolo" <Pa***@discussions.microsoft.comwrote in message
news:51**********************************@microsof t.com...
Learning C# and SQL Server. Just wondered what are the pros and cons of
either approach to using SQL Server databases.
To begin with, ADO.NET is the underlying technology for LINQ to SQL (and
Entity Framework), so it's not an either-or choice. If you use LINQ to SQL
or EF, you're still using ADO.NET, even if indirectly.
As to what it is - it's fairly simple. ADO.NET by itself is a rather
traditional API to work with SQL databases. It provides some straightforward
low-level abstractions such as DB connection, DB transactions, SQL command,
and a forward-only cursor to read query result. Otherwise, it does not
attempt to abstract away the relational data model or the SQL dialect used
by the specific database you're working with. You work directly with SQL
commands using syntax and semantics of the database you work against,
passing them as strings, and they are typically delegated straight to the
database server unmodified. Because of this, you can use ADO.NET to work
with virtually any database (well, so long as it has an ADO.NET or OLE DB
driver...), but it's hard to be compatible with multiple databases -
advanced SQL often becomes unportable quickly.
LINQ to SQL attempts to abstract away the SQL part by replacing it with LINQ
queries. To do so, it also dresses tables up as classes, and table records
as instances of those classes (but it doesn't go all the way full-fledged
ORMs usually do). It only works with SQL Server, though, and, apparently,
there are no plans to change that (now that Entity Framework is the next big
thing). But within its limitations, it's still okay - you get the
convenience of LINQ and static typing for your data, and you don't really
lose anything.
