Question

I’ve been programming in C# 2.0 WinForms for a while now. I’m starting to get into ASP.NET and the new MVC framework and the new features of C# 3.5. I’ve only read a little on LINQ to SQL but have made a few test apps to try it out. In my WinForms apps, I usually had some sort of data access layer, and wrote all the SQL myself. Of course, if something can do that CRUD for me, I’m all for it.

I followed the tutorials on the http://www.asp.net/mvc website and did both the Entity Framework example and the LINQ to SQL example. So far, they both seem pretty similar. LINQ feels more like SQL, but the Entity Framework feels more like C#.

My questions are:

1. Is one method better than the other?
2. What are the benefits of one over the other?
3. Is it possible to see the SQL that is generate when using either of the methods?
4. Since I’m new to the ASP world, are web developers leaning on one side?

Answer 1

2: LINQ-to-SQL has the benefits of being simple (but still well engineered) – but the downside of being simple ;-p

• LINQ-to-SQL only works on SQL Server (Entity Framework is pluggable; 3rd party variants of LINQ-to-SQL like DBLinq cover some other providers)
• Entity Framework supports more abstraction between the data (storage) model and the object model – LINQ-to-SQL is literal table/column => class/property[|field]
• LINQ-to-SQL is actually more “complete” in the stuff it does do:
  • EF doesn’t support UDFs
  • EF doesn’t support things like sub-expression invoke (for custom expression trees)
  • EF doesn’t support some “obvious” methods like Single()
  • EF doesn’t have some of the TSQL optimisations that LINQ-to-SQL uses

Basically EF at the moment is a bit more of a “v1” (or even “v0.9”) product. However (and importantly) – EF is likely to have a proper next version in .NET 4.0 etc, where-as LINQ-to-SQL is going to see a lot less change. It is still being maintained, but famously Microsoft have chosen Entity Framework as the flagship product (rather than co-evolve both products essentially into each-other). You should think about the long term plans.

At the moment, I’m very happy to use LINQ-to-SQL, but EF is on the long term… so I’m using repository etc to hide some of the gory implementation details – a bit of a leaky repository, but pragmatic.

3: With LINQ-to-SQL, assign a TextReader to dataContext.Log; Console.Out works well – or I have one that writes to the trace.asax. With EF, ToTraceString.

4: I suspect it breaks down a lot by complexity. People using SQL Server with simple models, or who are happy to have a storage model that shines into the object model tend to be using LINQ-to-SQL at the moment (from what I see). People with more complexity and other databases tend to use NHibernate ;-p And then some EF. I’m wondering how much this will change when EF is next released in .NET 4.0…