LINQ to SQL or Entities, at this point?

Question

I'm a bit late to the game and have decided to spend some spare time learning LINQ. As an exercise, I'm going to rewrite a WebForms app in MVC 2 (which is also new to me). I managed to find a few topics regarding LINQ here (Learning about LINQ, Beginners Guide to LINQ, Is LINQ to SQL Dead or Alive?), which brought the concern of Entities vs SQL to my attention.

The threads are all over a year old however, and I can't seem to find any definitive information on which ORM is preferable. Is Entities more or less LINQ to SQL 2.0 at this point? Is it still more difficult to use?

Is there any reason to use LINQ to SQL, or should I just jump into Entities? The applications I write at my present employer have a lengthy lifecycle (~10 years), so I'm trying to pick the best technology available.

Answer 1

In a recent post on extending NerdDinner, Scott Hanselman talked about this very thing. To quote at the end:

Conclusion

There's lots of choices for Database Access on .NET. You'll run into DataReaders in older or highly tuned code, but there's no reason it can't be hidden in a Repository and still be pleasant to use. LINQ to SQL is nice, lightweight and fast and has dozens of bug fixes in .NET 4, but Entity Framework is the way they are heading going forward. Plus, Entity Framework 4 is way better than EF 3.5, so I'm using it for any "larger than small" projects I'm doing and I'm not having much trouble.

Granted I haven't had a chance to play around with it much yet, but EF4 does seem to have gained the confidence of a number of pros.

Answer 2

Is there any reason to use LINQ to SQL, or should I just jump into Entities?

I'm hardly objective (as a die-hard LinqToSql user), but this is answerable.

Object Relational Mapping technologies are attempts to solve or mitigate Object-relational impedance mismatch. They are bridges between the two worlds - the object world and the relational data world.

And it seems that the developers of these bridges generally call one side or the other, home.

LinqToSql is an ORM from the object side. It was developed by the C# team and lets you use objects to represent data. In LinqToSql there are no compiler-opaque strings, all queries are checked by the compiler against the mapping.

EF is an ORM from the data side. It was developed by the ADO team and lets you use data represented as objects. In EF, there are plenty of opaque strings.

Queries have to ultimately run against a database, and the compiler cannot certify that the database available at run-time matches the mapping (true in either ORM). Because of this reality of the data world, the data team doesn't value compiler guarantees as much as the C# team.

Having worked in a TSQL backend for years, without the protection of a compiler, I happen to value highly any help the compiler is going to give me. And so I side with the C# team on this.

---

For example, loading a Customer with its Orders.

  //linq to sql.
DataLoadOptions load = new DataLoadOptions();
load.LoadWith<Customer>(c => c.Orders);  //<-- strong typed
myDataContext.LoadOptions = load;

IQueryable<Customer> query = myDataContext.Customers
  .Where(c => c.CustomerId == 1);

  //entity framework
IQueryable<Customer> query = myObjectContext.Customers
  .Include("Orders")  // <-- opaque string
  .Where(c => c.Customer.Id == 1);