Difference between Linq to SQL and the ADO.NET Entity Data Model

Question

Hi there,

I have been reading up on Linq to SQL and the new ADO.NET Entity Data Model lately. I have also been playing around with both of them in the latest Orcas CTP.

One thing that is still unclear to me is why both technologies exist at the same time. It seems that the ADO.NET Entity Data Model is capable of doing evertyhing that Linq to SQL can do, so what's the point of having the separate Linq to SQL technology?

Can someone explain the reasoning for having these two (seemingly) similar technologies? I read this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=670164&SiteID=1 but I was wondering if something significant has changed since the last post in that thread was made.

Thanks in advance for an answer.

Imar Spaanjaars
http://imar.spaanjaars.com/

 

Answer 1

No answer?

Is that's because the question is wrong, and the answer can be found elsewhere, or is it because it's unclear or difficult to correctly describe what the differences are?

Imar
http://imar.spaanjaars.com/

Answer 2

Hello Imar,

    I don't have an answer for you either.  I am, however looking into both of these technologies, and came across your post in a search on MS EDM.  I hadn't heard about EDM until I received a reply  to a post I made in another forum.

    I've been active in a couple of groups that are working on developing a framework and tool in support of Object Role Modeling (ORM 2 is the latest iteration of a modeling methodology, principally  building on the work of Dr. Terry Halpin).   Dr. Halpin is currently teaching at Neumont University in Utah.  He, along with some staff and students there are working on this framework called NORMA.  There have been several CTP releases of a tool to create and work with ORM 2 data models.  These are conceptual level models, but there are mapping capabilities, and more are being developed.  EDM is slated to play some part in these.  Also, the current versions of the tool run as add-ins to VS 2005 (Standard or above), via the DSL tools.

    Whether you are already familiar with ORM 2 or not, you might get something out of a visit to the principal site for ORM (Dr. Haplin's website): http://orm.net , as well as the NORMA site on SourceForge: http://sourceforge.net/projects/orm .  There is also a new mailing list/group: http://groups.yahoo.com/group/information_modeling/ that supports related technologies, and an ORM site that is being developed by one of the authors on the of the only book on creating ORM models using Visio for Enterprise Architects: http://ormfoundation.org .
Good luck with your questions.  BRN..

Answer 3

Besides that Linq to SQL is only for SQL () one of the big differences is that the EDM is more flexible and more loosely coupled because of the 3-tiered model (conceptual layer, source schema and the mapping layer in between).  For example, you could have one conceptual layer and then multiple mapping layers that point to mulitple databases. In LINQ to SQL, your dbml properties are tightly bound directly to one particular field in a table.

 

While these are not in the March 2007 CTP, EDM is getting the ability to build views of the conceptual layer as well as to write stored procedures in the mapping layer. These are really cool features. I don't believe you can do this with Linq to SQL, but a) I could be mistaken and b) that may be something that is forthcoming.

 

In addition to Linq to Entities, Entity SQL can be used to query entities. This can be either through the object services API or the Entity CLient (the one which gives you connections/commands and results in a dbDataReader). Entity SQL, while not as elegant as using the strongly typed LINQ, has the advantage of enabling dynamic queries, since you use a string to build a query, much like TSQL.

 

Both Linq to SQL and EDM allow inheritance and extending the code generated class with addtional partial classes.. EF also allows many to many relationships. I believe that LINQ to SQl won't be getting this by RTM.

 

These are just a few points and hardly exhaustive. But to me they are the low hanging fruit.

 

HTH

 

Julie

Answer 4

Thank you both for your answers.

 

Brain: I'll check out the links you posted; thanks for that.

 

Julie: thanks for your explanation. Although I still have some uncertainties about the overlap between the two technologies, your post really helped to clear some things up. I am currently researching Orcas for my new book, and I have come across a number of posts on your blog that helped as well.

 

BTW: Linq to Sql does allow you to use stored procedures for action queries. You can map the Insert, Update and Delete methods to stored procedures and then map sproc parameters to the object's fields. Additionally, you can drag sprocs on the diagram and they'll be turned into methods you can call directly.

 

Imar

http://imar.spaanjaars.com/

 

Answer 5

Imar

wrt Stored Procedures. This is even better than what you are referring to. Not only can you map to sprocs (both in EF and in LINQ to SQL) or override the update/insert/delete methods, but in EF, there is coming a capability to CREATE stored procedures right in the mapping layer. Not create them and add them into the db, but just have them live in the EDM. So the sproc doesn't have to exist in the db.

 

This is not in the March bits, but I saw a demo of it last week and we will have it in the next CTP.

 

julie

Answer 6

Sounds great. Can't wait for the next CTP to be released.... ;-)

 

Thanks again for the info,

 

Imar

Answer 7

LINQ to SQL actually stands for LINQ to 'databases that use SQL' or in other words LINQ for the relational data model.  LINQ to Entities means LINQ for the Entity-Data-Model which is a kind of a relational++ model.

 

Answer 8

"Wow" on that clarification, Matt. That's a pretty major misunderstanding I had. Thanks.

 

So should this mean that the providers that are coming for Entity Framework will likely also include inegration wtih LINQ to SQL also?

Answer 9

Hi guys,

 

Just a quick question. 

 

1. As long as I use ADO.net EDM (irregardless I'm using Entity SQL or LINQ to Entities), it would be db agnostic, right?

 

2. In ADO.net EDM, does it support LINQ to SQL and LINQ to Entities? If YES, how do I differenciate by syntax? Or both are the same thing/syntax under ADO .net EDM?

 

Thanks in advance.

 

Answer 10

thank you very much for this detailed answer, julia. I found the answer I looked for.



keep battling!
m e h m e t

Answer 11

Great Help guys,

For quick and better understanding visit these links:

http://blogs.microsoft.co.il/blogs/gilf/archive/2008/04/20/linq-to-sql-vs-entity-framework.aspx

http://www.osellus.com/blogs/2009/06/04/linq-to-sql-vs-entity-framework/

Cheers,

Ajay Shankar

NJ, USA

Answer 12

Hi there,

I have been reading up on Linq to SQL and the new ADO.NET Entity Data Model lately. I have also been playing around with both of them in the latest Orcas CTP.

One thing that is still unclear to me is why both technologies exist at the same time. It seems that the ADO.NET Entity Data Model is capable of doing evertyhing that Linq to SQL can do, so what's the point of having the separate Linq to SQL technology?

Can someone explain the reasoning for having these two (seemingly) similar technologies? I read this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=670164&SiteID=1 but I was wondering if something significant has changed since the last post in that thread was made.

Thanks in advance for an answer.

Imar Spaanjaars
http://imar.spaanjaars.com/

 

Hi I think you should read this http://msdn.microsoft.com/en-us/library/cc161164.aspx http://stackoverflow.com/questions/8676/entity-framework-vs-linq-to-sql