Well this is a problem with all the MS database solutions as far as I'm concerned - they are basically one way. You can't easily refresh the schema. IOW you can't just say "regenerate".

For LINQ there's already a work around with CodeSmith Templates that can be used to generate the DBML based XML content.

John I haven't run LINQ through all of its paces so I can't give you a concrete example, 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 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>).

There are other issues here as well though to consider especially in terms of performance. LINQ generates objects and binding list controls to LINQ requires Reflection. Out of all the binding mechanisms (DataReader, DataSet and LINQ/Objects) the latter is the slowest.

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.

There are lots of issues that conern me with LINQ to SQL on just a gut level at this point. The data generation is pretty major IMHO, but actually not that big of a deal to me as I have my own generator that I can tweak to actually build objects that can be regenerated and include additional functionality now missing (such as DataContract support for WCF).

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 (although the CRUD code is a no brainer).

Lots of things to think about in this space <g>...

+++ Rick ---




>Rick, can you tell me why this "schema change" issue gets applied exclusively to Linq to SQL?
>
>Typed Datasets, Stored Procedures and even the Entities Framework (that for some reason is presented as the golden child in this regard) all need to be updated to match a changed schema as soon as they encounter the change. Uncoupling in the EF does not avoid this problem though it may postpone it.
>
>Could it be because the whole Linq to SQL thing is so automatic and easy than when you hit a hurdle, it comes as a bigger jolt? And I think you might have a point that if too much is hidden inside the shiny shell, you're less in control when things go wrong. But that's also true of a modern car: what matters is how *often* things go wrong. ;-) From what you and Kevin are saying, they go wrong in Linq to SQL quite a lot. So, in the interests of argument I must say that I've seen some really *good* SQL coming out of Linq to SQL, especially if you break things into newbie functions and let Linq to SQL assemble a single uber-SQL. Obviously my "complex" queries aren't as grown-up as yours ;-) so can you provide some examples where Linq to SQL coughs? We might as well figure out what this thing is good for- though it's so accessible and productive that everybody might as well at least look at it.