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

It is not very adaptable to changes in the database schema. You have to rebuild the dbml layer and regenerate your data contexts.

Like any ORM (I am not getting into the debate as to whether it is an ORM or not), you do have to be aware what SQL is being generated, and how that will influence your calls.

Inserts are not batched, so can be high cost in performance.

It's being sunsetted in favour of Entity Framework

Despite the fact it is using a provider model that will allow providers to be built for other DBMS platforms, only SQL Server is supported.

[EDIT @ AugustLights - In my experience: ] Lazy loading may take a bit of hacking to get working.

That being said, I think it it is very handy if used correctly

Answer 2

Well, I have developed some applications using LINQ to SQL. One of the main problems that I find is having to layer your application. In LINQ to SQL the entity classes are tied very closely with the data access code. Also, there are some issues with DataContext which means that you can use a DataContext object to retrieve an item but you cannot transfer the item (object) to another DataContext (at least not easily).

LINQ to SQL will be useful if you don't care about layering your application properly and also if all you wanted is to create an application in a rapid manner also know as RAPID Application Development.

Answer 3

This question was asked once before over here. But, in essence, LINQ to SQL generates sub-optimal execution plans in your database. For every different length of parameter you search for, it will force the creation of a different execution plan. This will eventually clog up the memory in your database that is being used to cache execution plans and you will start expiring older queries, which will need to be recompiled when they come up again.

As I mentioned in the question I linked to, it's a matter of what you're trying to accomplish. If you're willing to trade execution speed for development speed, LINQ to SQL might be a good choice. If you're concerned about execution speed, there are other ORMs/DALs/solutions available that may take longer to work with but will provide you with future proofing against schema changes and better performing solutions at the cost of additional development overhead.

Answer 4

The only thing I would label as a technical "showstopper" is if you want to use other RDBMSes than SQL Server. (although it can be worked around - see Matt Warren's blog @ http://blogs.msdn.com/mattwar/ )

Besides that, there are some pros and cons already listed in previous answers to your question. However, all of the negatives mentioned so far have workarounds so they are not really showstoppers.

A non-technical [potential] showstopper is the risk that MSFT will abandon it in favour of EF... More on that here: http://oakleafblog.blogspot.com/2008/05/is-adonet-team-abandoning-linq-to-sql.html

Although (in my opinion, ) the current state of EF is reason enough for them to continue work on L2S. So let's hope they do...

Answer 5

• There is no way to mix-n-match lazy loading / eager loading on a datacontext.
• True persistance ignorance is very difficult.
• Mapping options are limited. For example, there are no many-to-many relationships.
• Resyncing the mapping with schema changes is painful.

Despite all of the above I think linq-to-sql is an excellent choice for many projects.