ASP.NET MVC + LINQ to SQL or Entities?

Question

When linq to entities was released, everybody say that linq to sql is dead.

But most books and sample projects by microsoft employees, use mvc+linq to sql.

There is some reason for that? The linq to sql seems better for POCO, would it?

Answer 1

The nerddinner sample chapter written by ScottGu uses Linq-To-SQL, he does not endorse LINQ-to-SQL but does not promote LINQ-To-Entities either. With ViewModel (Stephen Walther has a nice post on this) & the repository pattern, LINQ-To-SQL is perfect for developing ASP.NET MVC applications

Answer 2

The only reason the samples were written with LINQ-to-SQL is because setting it up is fast and simple.

Otherwise you can use any ORM to suit you, whether it be EF or NHibernate or whatever.

Answer 3

In my opinion, Linq to Entity is not a good candidate at the moment. One of the things that I've come to dislike about Linq To Entity is the lack of lazy loading, which drove me up the wall every time i wrote my repositories. I think, that's what killed it for me. The other thing is the whole issue with attaching and detaching entities which are being used by multiple instances of the object context. That was another killer for me, which resulted in a lot of hacking trying to recreate entity relationships and etc. Frankly, I think a better thing to do would be to wait for the next release of this framework. I think good things are coming for it :)

Answer 4

Linq to SQL had its origins in a thought experiment. Linq needed a proof of concept, and Linq to SQL provided that.

Since then, many in the user community (including a few prominent Microsoft employees) have embraced Linq to SQL as the lightweight SQL Server ORM of choice, especially for small projects like NerdDinner.

The furor began with this post by the ADO.NET team. In it, they said that Linq to SQL will be maintained, and features added based on user community feedback, but that the Entity Framework would be the primary focus of future data access efforts.

Many in the user community interpreted this move as "Microsoft is killing Linq to SQL."

Microsoft didn't help matters when it disabled the provider model for Linq to SQL by sealing some critical classes, effectively making Linq to SQL usable only with SQL Server. The Entity Framework will be the ORM of choice for multiple data providers.

Unfortunately, the Entity Framework seems not quite ready for prime time.

So it depends on who you believe. Do you believe the speculations (and they are just speculations) of many bloggers who say that Linq to SQL is truly dead and buried, or do you believe people like Damien Guard of Microsoft, who says that Linq to SQL has a long life ahead of it?

Answer 5

Personally, I'd start getting used to the Entity Framework now. Since it has more features, is provider-independent, and being developed (perhaps) more aggressively. The two most common complaints I hear are lack of POCO and lack of Lazy Loading. It would appear that both of these are addressed in .NET 4.0 http://blogs.msdn.com/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading.aspx

Besides being potentially faster (to get started with) or simpler, I'm not sure of any particular advantage to use LINQ to SQL, in the long run. Is anyone aware of any?

Answer 6

Linq-to-SQL is a great technology and very easy to use, so it's extremely well geared towards demos, and it's a perfect choice for smaller, more straightforward projects, too, where you have more or less a straight 1:1 mapping from your tables in SQL Server to your objects in memory.

And those are the most restrictive limitations of Linq-to-SQL:

• SQL Server only
• straight 1:1 mapping from tables to objects in memory

If that's okay with you, go ahead and use Linq-to-SQL ! By all means - MS is still adding features and fixing it for .NET 4.0 - it's not dead by a long shot.

Entity Framework in its v1 version available right now has some warts, as other posters have rightfully mentioned (no POCO support, no "domain design first" approach and many others). But the EF v4 feature set looks very compelling, and will give Linq-to-SQL a run for its money!

The main advantages for EF vs. Linq-to-SQL in an enterprise environment are its database independence (you can hook it up to Oracle, Firebird, DB2, many others) which can be crucial, and it's ability to present you with an object model that looks quite different from the physical storage model in the database (by virtue of the mapping between the conceptual layer and the physical storage layer).

So it's really a matter of what is it you need: do you need a quick way to get started (demos, simpler apps) - then your choice clearly is Linq-to-SQL (at least for now), or do you need a flexible mapping approach against a non-SQL Server backend - then your choice will be Entity Framework.

Marc