Personally I see the allure of LINQ in the CRUD support. The querying functionality is nice, but that's clearly not as important as the CRUD layer IMHO. I know blasphemy around Fox folks, but hell, with a decent business layer SQL queries have never really been a problem in the first place.
But even with the CRUD support there are issues (see my last two blog posts
http://www.west-wind.com/WebLog/posts/134095.aspx,http://www.west-wind.com/weblog/posts/134706.aspx) that are problematic in middle tier scenarios.
If you have complex SQL reports and queries I suspect that it'll actually still be preferrable to retrieve data using ADO into a DataReader. Not only is that more efficient but it will give you the control required.
LINQ to SQL is a mixed bag for sure and I by no means am sold and in fact the more I look at it the less excited I become about it as it looks more and more as a purely 2 tier solution.
+++ Rick ---
>
but just looking over the syntax you can see that it doesn't support all of SQL Syntax, so it figures that you won't be able to run every SQL type query with linq. >
>That's one of the two big issues I have with LINQ to SQL - the # of T-SQL '05 language features that don't translate well (or at all). And unless MS comes up with equivalents for some of the new language features in T-SQL '08 that we'll see early next year (e.g. OLAP-style grouping), the gap is going to get larger.
>
>
That said the SQL LINQ does generate looks pretty good I agree as good or better as I would generate by hand (and well, my SQL's not exactly stellar as it is <s>). >
>Don't sell yourself short. ;)
>
>For simple/basic queries, LINQ to SQL does a good job - but it doesn't take long before you see instances where the generated code is less efficient than if you were doing it yourself. In some instances, the generated code (e.g. correlated subqueries) is precisely what some SQL authors instruct NOT to write.
>
>There's an argument to be made that some of the generated code takes the path of "less" resistance. I realize the complications of writing a good SQL code generator, but that's sort of what I think it's best to stick with SQL in the first place.
>
>This is the 2nd big issue I have with LINQ to SQL, and I'm going to post what I've come across on this.
>
>Like I said, other areas of LINQ bring value over what previously existed - but LINQ to SQL just isn't quite there, IMO.
>
>
Compared to say loading data into a DataReader and binding to that LINQ can be very slow on large data sets displayed. I haven't run through this excercise of perf testing but I bet this actually will have a significant impact if not using paged databinding. >
>You're probably right - I use paged databinding (and I do the paging back in the database), and so long as I provide general navigation and soemthing for a user to easily hop from the 'A' records to the 'M' records, users are happy.
>
>
But the biggest issue that I'm still not sure how to address is the Anonymous type issue of result sets returned out of business objects. Since the anonymous types returned as var aren't scoped outside of the originating method I'm really unsure how to build a business layer that effectively uses LINQ for querying
>
>Agreed - your blog post earlier in the year really hit the nail on the head.
