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

For a project that needs to make use of databases other than SQL Server:

1) You are locked in to using SQL Server

For a project with complex entity relations and/or relations that change gradually over time:

2) You are locked in to 1-to-1 mapping of tables to classes

For a project that must use 1.x versions of .NET

3) Won't work with .NET 1.x

Answer 2

A true ORM should separate the design of your Business Entities from your persistence medium. That way you can refactor either one of them separately and only have to maintain the mapping between the two. This reduces the amount of application logic code that you need to maintain for database changes.

To accomplish this kind of persistence agnostic approach with Linq-to-SQL, you would have to use its generated classes at DTOs and maintain a mapping logic between your DTOs and your Entities.

There are much better ORMs for taking this approach (like NHibernate) that greatly reduce the need for DTOs.

Answer 3

It doesn't appear to have any support for default values on DB columns.

Answer 4

It is difficult to mock while unit testing because of a lack of an interface on the System.Data.Linq.DataContext class. Here's a possible approach: Mocking LINQ to SQL DataContext.

Answer 5

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.

Answer 6

because you are not using 3.5... is that a valid answer?!?!?