Login    Join Now
Home  /  Questions  /  Question



139   96.7
Jun 03, 2010


When to use LINQ-to-SQL versus Entity Framework?

My question is this: when should I decide to use LINQ to SQL over Entity Framework?  I my view, LINQ to SQL is far more 'agile' and flexible than Entity Framework. 

I know that Microsoft is totally committed to Entity Framework, but using EF does not come natural to me. I am very experienced with SQL and the whole LINQ to Entities or eSQL API feels awkward: for example, the Attach concept, the Include concept, etc).



7 answers
answer date votes comments
1,128   99.9
Jul 08, 2010
Here's the latest comment I have found from Microsoft regarding Linq2Sql and EF...
http://msdn.microsoft.com/en-us/data/bb525059.aspx

1,128   99.9
Jul 01, 2010
Don't forget that there exist solutions outside of Microsoft as well (which has its pros and cons).
Some popular ORMs out there...

NHibernate, http://nhforge.org/
Subsonic, http://subsonicproject.com/
LightSpeed, http://www.mindscape.co.nz/products/lightspeed/
LLBLGEN, http://www.llblgen.com/defaultgeneric.aspx

Some of the above are commercial others OSS. NHibernate is a popular and mature ORM with origins from Java's Hibernate. There is a comparison between EF4 and NHibernate here. Note that the comparison might be a bit biased, since Oren is a contributor to NHibernate. Nevertheless it is a good read.

Good Luck!

264   99.7
Jul 01, 2010
Personallly I would use EF.  EF is a true OR/M where Linq 2 Sql is mostly a SQL obfuscator. With EF you can save/load and manage your objects where with Linq2Sql you still need to know the sql and data structure but you are pretending you don't.

555   99.9
Jun 14, 2010
On BASTA! Spring 2010, a presenter said the following:

"Don't choose Linq2Sql if you are starting a new project, the team that developed it, doesn't exist anymore. Choose EF 4.0. This is the way to go. Linq2Sql was merely one possible way which we decided to not follow anymore."

50   50
Jun 09, 2010
I wouldn't quite go that far.  The links above are outdated.  Microsoft has made some updates to Linq2SQL in .NET 4.0

http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40

http://blog.linqexchange.com/index.php/linq-to-sql-changes-in-net-4-0/

1,128   99.9
Jun 09, 2010
I have not used any of them, but just wanted you to give a heads up if you start using Linq2Sql. It seems as the future for Linq2Sql is very uncertain, and Microsoft might make it obsolete in favor for EF. Something for you to consider when deciding upon which technology to use.


Reference:

Update on LINQ to SQL and LINQ to Entities Roadmap
http://blogs.msdn.com/b/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx

Microsoft kills Linq to SQL
http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

588   99.9
Jun 05, 2010
The primary difference between the two frameworks is how they handle your models.  That should be clear enough.  ;^)  Just kidding, partly. 

The basic rule of thumb for which framework to use is how to plan on editing your data in your presentation layer. 

  • Linq-To-Sql - use this framework if you plan on editing a one-to-one relationship of your data in your presentation layer.  Meaning you don't plan on combining data from more than one table in any one view or page.
  • Entity Framework - use this framework if you plan on combining data from more than one table in your view or page.
To make this clearer, the above terms are specific to data that will be manipulated in your view or page, not just displayed.  This is important to understand.

With the Entity Framework you are able to "merge" tabled data together to present to the presentation layer in an editable form, and then when that form is submitted, EF will know how to update ALL the data from the various tables.

There are probably more accurate reasons to choose EF over L2S, but this would probably be the easiest one to understand.  L2S does not have the capability to merge data for view presentation.

I hope this answers your question.

King Wilder
 1 comment
 
Actually there is a bit of a difference in how we look at Linq to Sql, In the recent past I worked with Linq to Sql and found that we could use composite/associative objects (objects made out of multiple table at DB), by using stored procedures, which only requires you to have a LINQ Xml definition for that custom object schema that you are returning through the procedures. One of the issues that I found with Linq to Sql is that, we have to be extra careful when changing any of the database object names like table column, sp parameter name/type and you will have to adjust corresponding mapping files accordingly. Sandip --- Sandip Nandi  Jun 09, 2010

 







Company
Customers
Community
Reference Guides
Our Products
© 2017 - Data & Object Factory, LLC.  dofactory.com.  All rights reserved.