>I'll clarify - yes, there are some benefits of using LINQ to call stored procs. What I'm referring to is using dynamic SQL with LINQ to SQL, versus writing stored procedures.

Huh? You can do either with LINQ.

But yes completely dynamic SQL isn't likely to go away. I'm sure there will be lot of scenarios that the LINQ parser can't address through the C#/VB query syntax. When that happens you still will need to use ADO.NET to retrieve data some other way whether it's into a DataSet or a DataReader.

>It's rather interesting to read from SQL folks about performance (e.g. correlated subqueries versus derived tables), and then look at LINQ to SQL generated code. Topic for a blog entry.

If you want the ultimate in performance you use a Command object and a DataReader and you skip any sort of object conversion.

But that's not quite the point as it wasn't with DataSets. There are certain things (especially CRUD) where performance issues are negliable and this is really where LINQ excels. Long query performance is also likely to be much more efficient than going into DataSets which are extremely heavy in object and memory use.

Compared to DataSets LINQ Resultsets compare very nicely.

The way I see it LINQ to SQL is capable and much cleaner alternative to DataSets which have always sucked (although they are in some situations the best that .NET can do natively).

+++ Rick ---


>Yeah, I'm looking forward to Beta 2 for the EF, I hope they keep the staggering to a minimum.
>
>Compared to what? DataSets? <s>
>
>Not sure I understand the point. DataSets come in rather handy for many apps, such as reporting apps, when the report can't see the database.

Any object can serve that purpose - it doesn't have to be a data set.

+++ Rick ---