What's wrong with Linq to SQL?

Question

What\'s wrong with Linq to SQL?

Or - what about Linq to SQL would make it unsuitable for a project, either new or existing? I want to hear about why you would

Answer 1

A lot of the advantage to LINQ-to-SQL comes from supposedly being able to construct data queries right in your code-behind based on strongly-typed queryable/enumerable data objects from your dbml (which plays the role of a very limited DAL). So a consequence, as has already been mentioned, is that it encourages you somewhat towards playing outside strongly defined and separated layers or tiers to your application.
To counter that point, it should mean that you should be able to eliminate most or all of any business logic you were writing into stored procedures on the database, so then at least you only have to go to the code that deals with the data to change non-schema-impacting business rules... However, that breaks down a bit when you realise how complicated it can be to write a query with an outer join with aggregates with grouping, at least when you first approach it. So you'll be tempted to write the sprocs in the SQL you know that is so simple and good at doing those things rather than spend the extra time trying to figure out the LINQ syntax to do the same thing when it's just going to convert it to ugly SQL code anyway...
That having been said, I really do love LINQ, and my esteem for it vastly increased when I started ignoring this "query syntax is easier to read" sentiment I've seen floating around and switched to method syntax. Never looked back.