5

I have been using ADO.NET in favor of LINQ to SQL (or Entities) up to this point. I'm starting a new project that should be smallish, at least at first but I would like to have room to expand down the line.

I feel now is a good time to get into LINQ. I've avoided it for quite a while; however, I'm concerned by the current direction of LINQ to SQL. I hear LINQ to Entities is going to be MS's preferred data access in the future. I'd rather not get into LINQ to Entities because: 1.) Most likely a steeper learning curve that I don't want to throw into the mix right now (already busy learning MVC) and 2.) I hear it's not ready for primetime.

My concern is this - if I start a project with LINQ to SQL now, can I easily upgrade it to LINQ to Entities down the line?

Michael Maddox
  • 12,331
  • 5
  • 38
  • 40
Mike
  • 2,912
  • 4
  • 31
  • 52

6 Answers6

11

LINQ to Entities is ready for primetime, and not necessarily much steeper to learn. However, LINQ to SQL is fine too, you'll learn a lot that will stay useful as you move forward.

In short, choose whatever suits the project best. If SQL Server is and will remain the DB platform, and if there's no need for remapping tables or other sophisticated tricks, LINQ to SQL will get you there very fast. It's also very efficient.

Tor Haugen
  • 19,509
  • 9
  • 45
  • 63
  • 4
    LINQ to SQL is also a good pick if you enjoy mindlessly rebuilding your .dbml file every time you make a change to your database. – James Jones Oct 03 '09 at 14:16
  • 1
    @James Jones Not if you're using something like PLINQO – CitizenBane Oct 03 '09 at 14:28
  • 1
    ....or http://www.huagati.com/dbmltools/ - it lets you use the out-of-the-box L2S designer yet adds true 'changes only' synchronization, naming conventions, Xml doc comments, SQL-DDL diff script generation from L2S models etc. – KristoferA Oct 03 '09 at 14:38
  • There *is* a bunch of stuff that L2E is good at, but in terms of getting up and running, there's basically no learning time in L2S. You can certainly upgrade your project to L2E later. If you're careful about applying the repository pattern, switching O/RM frameworks is pretty trivial. – Iain Galloway Oct 03 '09 at 15:15
  • 2
    Because patching LINQ to SQL's gaping holes with 3rd party utilities is exactly what I want out of my ORM solution. This is the kind of stuff I'm talking about. But hey, if you don't mind these sorts of things, by all means... I won't stop you. – James Jones Oct 03 '09 at 15:26
4

If your app is going into production before .net 4.0 SP1 is available, go for L2S. Linq-to-SQL is stable, it will not go away anytime soon, and it generates great SQL. EF v1 don't. Period. Check out the MSDN EF forum if you want to know more about the EFv1 childhood diseases.

Whether EFv2 will be up to the task remains to be seen; I have only used beta 1 and that one does not have some of the improvements that later versions are said to have.

The "L2S vs EF" topic has been covered numerous times already, check out:
Is LINQ to SQL Dead or Alive?

...and personally, I think that Anders Hejlsberg's statement to Redmond Developer News makes it clear enough. "LINQ to SQL is not dead. I can assure you, it is not dead. Nothing ever goes away. We have never done that and we never will," he said.

http://reddevnews.com/blogs/desmond-file/2008/12/digital-darwinism.aspx

Community
  • 1
  • 1
KristoferA
  • 12,287
  • 1
  • 40
  • 62
1

I've steered clear of the Microsoft ORMs and I'm rather glad that I have. There's a constant cycle of hype -> acceptance -> realization of weaknesses & flaws -> end-of-life, begin again.

Don't get me wrong, I'm a huge fan of .Net, just not Microsoft ORMs. There are better solutions out there.

I realize this is just opinion but I offer it for what it's worth.

Matthew Lund
  • 3,742
  • 8
  • 31
  • 41
0

Microsoft issued a statement that LINQ to SQL has reached its end of life and will no longer be providing any major improvements to it. Check out their official sugar-coated statement here. The Entity Framework will be taking its place.

Here is the MSDN article on how to port a LINQ to SQL project over to the Entity Framework.

James Jones
  • 8,653
  • 6
  • 34
  • 46
  • 1
    They won't improve it, but they won't take it away either. In fact, the same is true for Windows Forms, it doesn't mean you shouldn't use it. – Tor Haugen Oct 03 '09 at 13:51
  • 3
    Winforms had a chance to mature before WPF took the reigns. LINQ to SQL, on the other hand, is still relatively new. – James Jones Oct 03 '09 at 13:57
  • But does that mean you shouldn't use it anymore? What works now will continue to work in the future, and while MS won't add new features to it, it will still support it in terms of fixes (I believe some fixes are coming with .NET 4.0). – JulianR Oct 03 '09 at 14:01
  • 1
    I never claimed that Beavis should *not* use LINQ to SQL. I'm merely laid out the facts. Sure, they're still keeping LINQ to SQL around. But if LINQ to SQL and the Entity Framework are solutions to the same problem, and MS issues a statement that they will be stopping development on one platform in favor another, it's not unreasonable to speculate that the surviving technology is the wiser choice. I like LINQ to SQL and I have used it, but I think (purely on speculation) that it will become the red-headed step-child of Microsoft's ORM solutions. – James Jones Oct 03 '09 at 14:10
  • The question has to bae asked though: What if you like red-heads? – Matthew Scharley Oct 03 '09 at 14:18
  • 1
    It's not about whether any "major improvements" are coming. It's about picking the right tool for the right job. I hear that the wheel hasn't had any major improvements for quite some time now! The fact is that L2S will most likely get the OP where he is going with next to no effort. There's no learning curve, there's no investment. If the project is going to ship before 4.0, and you only need to support SQL Server, I'd go with L2S. If you're even a bit careful, you can replace your DAL with minimum impact if MS decide to magically make your working L2S code stop working... – Iain Galloway Oct 03 '09 at 15:09
  • LINQ to SQL has not reached the end of it's life so you're hardly "laying out the facts". The fact is Entity Framework is getting more resources than LINQ to SQL. – DamienG Oct 08 '09 at 15:41
  • Why would MS continue to support an ORM that conflicts in interest with their mainstream ORM? I don't see how that makes sense. – James Jones Oct 08 '09 at 16:24
0

The people who say LinqToSql has a minimal learning curve are not being completely honest with you. ADO.NET has a significant learning curve. Any ORM has a significant learning curve. Once you've used one ORM, it's not too difficult to pick up another ORM. Once you've built your own ORM (for fun, don't do it for real), you'll really get what's going on.

Linq (I'm not talking about LinqToSql) is a great technology and you can't use Linq with ADO.NET, you need something like an ORM.

For many reasons (Linq being one of the stronger ones, ORM maturity being another), now is a great time to move from ADO.NET to an ORM.

From what I've seen, "upgrading" a project from one ORM to another (it doesn't matter which ORMs) is always difficult, unless you really know what you are doing and keep your ORM as loosely coupled from everything else as possible.

I would beware of both LinqToSql and EntityFramework (aka LinqToEntities). They are both lacking quite a few features that you'll likely need in the "real world". Neither are mature or proven (as the disagreements you've seen in the answers to this question help show).

There are mature, proven ORMs in the .NET space and it's not too hard to figure out which one is dominate right now.

Michael Maddox
  • 12,331
  • 5
  • 38
  • 40
0

It may be that LINQ to SQL is optimized for SQL server, to it may be a better fit for your problem than Entity Framework.

However, in the long run, you must consider how long your application is expected to live and what the cost of "upgrading" would be.

Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252