LINQ to SQL != Typed DataSet Replacement
A couple of questions I have received while giving talks, not to mention a question I see when lurking in, and occasionaly responding in, the Microsoft LINQ forum, is that LINQ to SQL is not feature complete when compared with Typed Data Sets.
My response is, of course, is that LINQ to SQL is not designed to replace Typed DataSets (TDSs). The reason for existence of TDSs is to do an end-run around having a whole mess of business logic and other things that get between a bound control (such as a grid), and a database table or CRUD stored procedure set. And at that, so long as your business logic is all in stored procs, or in the presentation layer, is great. And no, I am not being facetious - as I have indeed used them in the past to bang out quick forms over data apps or prototypes.
That said, in the new world, having an architecture that allows for TDD is, and it pains me to say this, almost mandatory. That means your objects have to be mockable. Which of course means that you have to have a reasonable amount of seperation of concerns in order to make that happen. Given this reality, it is no suprise that with LINQ to SQL, Microsoft has moved away from datasets that have things like caption properties that tell the header in some form down the road what to display. That kind of mixing of presentation and DAL logic is, what do we say... not "politically correct" anymore.
In fact, it probably isn't technically a good idea either - especially in a world where maintainability finally is considered important. Given that frameworks change, DALs change, technical fashion changes, I want all my business logic to reside in PONOs that are framework independent, or if they are going to utilize an inheritance based framework, one that is likely to be around for a good deal of time, such as CSLA.
In that light, one needs to a.) differentiate between LINQ in general - which is a mechanism that allows for set based manipulations of collections, b.) LINQ to SQL, which is an implementation if IQueryable<T> for hitting SQL Server databases, useful in a data access layer, and c.) Typed Data Sets - which is another way to implement a data access layer where you intend to use the data access layer as your business object as well (noting that you could, in theory, use the partial classes feature to write business logic in a TDS - but you would have the same mocking problem as above).
In other words, if you need your data and business layers to be the same thing - use Typed data sets. If you are implementing TDD, consider LINQ to SQL, or NHibernate, or any other framework designed more for seperation of concerns.
Lastly, yes, I know that people have asked about mockability of LINQ to SQL objects - though if you are using them as DTOs only, I would see that as less of a problem- you could create an interface that the LINQ to SQL oriented DTOs implement that could also be implemented by a mock object - though if you really want to test your queries - particularly the ones that LINQ to SQL generates, you probably need to be doing integration testing, and not unit testing, anyway.