Linq to Entities and Linq to SQL
I've just about finished reading the ADO.NET Entity Framework Overview document and have been playing with Linq, Xlinq, Dlinq (apologies for no political correctness in what these are all called now).
One thing i don't quite get is why the distinction between ADO.Net entities (Linq to Entities) and Linq to SQL - other than for historical reasons. Now i think i grasp the intentions and purposes of both (disclaimer : i haven't read all the docs about dLinq quite yet!), but why they are defined as being different is a little confusing for me.
Would Linq to SQL not be regarded as conceptual "Linq to Entity" - that is ADO.Net entity over a single table? In other words, although they operate on a slightly different basis, should I, as a consumer of the entities really care?
It just (at the moment) seems they have different sources, but ultimately Linq to SQL is a subset of the more general Linq to Entities. And if this is the case then paragraph 4.4 may lead to some confusion.
However, others may see this differently, so glad to hear if they do (or there is more to it than i think!).
steven
http://stevenR2.com
Since LINQ to Entities is relatively new, I haven't had a chance to dig into it too much yet. As I understand it, though the main thing LINQ to Entites gives you (over LINQ to SQL) is the ability to flatten table relations. In order to do this, there is a mapping process between the eSQL and the underlying TSQL for the individual tables that need to be modified. Even if only one table is used (as is the case of LINQ to SQL), the runtime would need to parse your LINQ to Entity statement into eSQL (using the expression trees) and then map from the eSQL into TSQL statements to send to the database for execution.
In the case that you don't need the entity mapping portion (ie. for simple admin/utility forms where the conceptual model maps directly to the table structures), LINQ to SQL may suffice and offer less overhead and thus better performance.
Another consideration is dynamic queries. LINQ shines when using declaritive syntax. When moving to dynamic queries, things get a bit more tricky (dynamically building expression trees is as fun as working with the codedom). eSQL allows you to build your queries as strings (you loose some of the strong typing) and pass that on as you would a standard LINQ to Entities statement.
Jim Wooley
http://devauthority.com/blogs/jwooley
I don't see a purpose for DLinq / Linq for Sql: it is surpassed in every way by Linq for entities. IMHO, Ms keeps it around,
for now, to not dissapoint the Linq folks at the C# team, at least that's my impression.
 jwooley wrote: |
Since LINQ to Entities is relatively new, I haven't had a chance to dig into it too much yet. As I understand it, though the main thing LINQ to Entites gives you (over LINQ to SQL) is the ability to flatten table relations. In order to do this, there is a mapping process between the eSQL and the underlying TSQL for the individual tables that need to be modified.
|
|
No that's not the case. Linq to entities converts Linq's Expression trees into an intermediate format, which is the same format as the eSql consumer converts to,
so there's no conversion to eSql first.
In the case that you don't need the entity mapping portion (ie. for simple admin/utility forms where the conceptual model maps directly to the table structures), LINQ to SQL may suffice and offer less overhead and thus better performance.
|
|
No, there's no extra overhead. Linq to sql (DLinq) is doing o/r mapping as much as Linq to entities does so there's no difference. That's the odd part.
| Another consideration is dynamic queries. LINQ shines when using declaritive syntax. When moving to dynamic queries, things get a bit more tricky (dynamically building expression trees is as fun as working with the codedom). eSQL allows you to build your queries as strings (you loose some of the strong typing) and pass that on as you would a standard LINQ to Entities statement. |
|
This is indeed a good point, and also shows why DLinq has no real purpose.
| Paul Gielens wrote: |
What if I'd choose to skip the level of indirection that conceptual views bring to my application? Assuming a straightforward mapping is sufficient. Thus: object-edm-target vs. object-target.
|
|
A default mapping from a db schema to the EF would be enough... The main issue to achieve it today is that you need the .xml files + the generated classes in the EF vs just the generated classes in LinQToSQL, so is a little more troublesome, but if the EF supports mapping through attributes in addition to mapping using xml files, then it would be the same thing.
Regards,
Andres
