Is there any reason to keep using Linq to SQL, or is it better to move to ORM techniques like EF, NHibernate etc.

We are using Linq to SQL in a new large enterprise application that will exist for a long time. The motivation for this new enterprise application is that the application was ordinary written in Visual Basic and since Microsoft stopped the support we where forced to rewrite the application. It’s seems that we are already there but this time with our DAL (Data Access Layer).

I have already read this article, but it only compare to EF's weakness.

  • +1 great Q. This is fascinating to me, I've been condsidering moving my stored procedures and paramterised SQL query strings to LINQ to SQL for improved readability, I had no idea it wasn't being developed anymore. – fearoffours Nov 12 '10 at 9:20
  • MS has a little .NET 4 slideshow type of thing that said it's not dead - but that can mean many things. They did improve it in .NET 4.0: damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40 – MetalMikester Nov 13 '10 at 0:25
  • Not again. This question has been debated ad-nauseum on StackOverflow. Can you say FUD? – Robert Harvey Nov 15 '10 at 16:44

If you're already using it and not encountering any difficulties, I'd stick with it on existing projects.

Linq2SQL is quite a nice, but limited, ORM - if you want to map your objects in more complex ways than the basic ones provided by Linq2SQL then you're going to be stuck. Microsoft did fix a few bugs when they came out with .net 4 but have stated that they're not going to be devoting resources to extending it.

I'd say if you have a fairly simple project which possibly has a limited lifespan then Linq2SQL is a decent lightweight choice so long as you're careful not to leak dependencies to Linq2SQL all over the place. For anything more I'd go with something else (NHibernate or EF for example) as Linq2SQL is pretty much a dead end.

|improve this answer|||||
  • I can only agree, not really dead but it's on the table in the triage in some way. If stuff is working and it's a huge impact to change it now...well you might wanna sit back a bit and look for a good time to put the conversion to EF/NHibernate, could be a financed upgrade project (in the end we all want a job, bread and butter on the table). – cyberzed Nov 12 '10 at 10:28
  • @cyberzed: That sounds like a good excuse for unnecessary work. – Robert Harvey Nov 15 '10 at 19:13

It's not dead, but Microsoft is now focused on the Entity Framework.

I've used LINQ to SQL on small projects, and it's quite nice as a lightweight data-layer and i'd consider using it again on similar sized projects. The LINQ implementation itself is really good and until recently much better than the NHibernate LINQ project. On the larger project I used L2S on, I found it hard to come up with a unit-of-work pattern that I was happy with, due to limitations with the L2S 'DataContext' class. Trying to implement something like 'Session per request' with L2S seems either very difficult or impossible.

I also wouldn't really consider L2S as a true ORM, as it really doesn't give you many mapping options. Your class design really needs to follow your database schema (table-per-class) otherwise it will fight with you every step of the way. Another thing I don't like about L2S is the need to use specific types (EntitySet and EntityRef) to handle collections, references and lazy-loading. This means it's not possible to keep your domain model ORM agnostic without adding another layer of abstraction.

My other issue with L2S is the sole reliance on LINQ to generate queries. The LINQ provider is very well written and generally creates decent SQL for the majority of queries but I have my concerns that there are more complex queries that can't be expressed well with LINQ. Using L2S you basically have to revert to calling stored procedures in these cases, whereas (for example) NHibernate has several API's (LINQ provider, QueryOver, HQL etc) that can be used when you want more control over the generated SQL.

In L2S's defence over NHibernate, there is a lot less overhead in getting it up and running on a project.

|improve this answer|||||

It's not dead as it still works, but if it's not being developed further then it can make sense to move to something else.

However, if it works for your application there's no point in changing for the sake of changing.

|improve this answer|||||

more stable than dead imho:



They have shifted their improvement effort over to Entity Framework where it is really needed if that product is to succeed. Expect nothing new but compatibility and bug fix on linq2sql for a while.

This site is run with a whole lot of linq2sql if I am not mistaken.

|improve this answer|||||
  • +1 for "stable" Best way to view L2S, imho. Stable and no longer being extended/changed. – quentin-starin Nov 15 '10 at 19:33
  • Sorry but "nothing new but compatability and bug fix" means its in containment. That is basically a guarantee that the community will move away from it, you won't see lots of new projects using it and so you probably don't want to use it in new projects either. "Dead" doesn't mean it doesn't work, it just means there is little innovation or interest. – Jeremy Nov 15 '10 at 20:25
  • From a large enterprise point of view the fact that the core is no longer being modified means it can finally go on the list of approved techniques in many cases. In my line of work we have been waiting for this for some time. EF is still to volatile to jump into yet and L2S is always going to attract interest in situations where the overhead of EF is not wanted. – Bill Nov 18 '10 at 19:54
  • @Jeremy Do people still use TeX? – alternative May 1 '11 at 21:56

It is weird but I have seen this phrasing a lot (“LINQ2SQL is dead”) and I’m not sure where it stems from*. It is just as dead Windows XP. Microsoft has discontinued support and has created something new (and in my eyes better) yet people are still free to use XP just as they are free to use Linq2SQL. Admittedly, I use Linq2SQL when creating custom DotNetNuke modules. However, with new features in EF4 such as code-first-development (http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx) it is hard to find reasons to stick with Linq2SQL. I don’t see a reason to go through and update code but for new code I don’t know why you wouldn’t want to use EF4.

*In all honesty though, I’m very…obsessive over semantics! I apologize if it is annoying to others :)

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.