-1

I'm new to Entity Framework and I just want to know what is the difference between these two code lines:

using (dbStudentEntities db = new dbStudentEntities())
{
    var classList = (from cl in db.tblClasses
                     select cl.className).ToList();

    var classList2 = db.tblClasses.Select(clss => clss.className);
}

It returns the same result. But what are they called? And what is better to use?

user1672994
  • 10,509
  • 1
  • 19
  • 32
  • In addition to the answer below, it's also worth noting that the second call will not actually query the database, while the first one will (because of the `ToList()`). – vesan Jun 07 '18 at 01:46

4 Answers4

0

In your first example that is using the expression syntax using the query operators of the language. The compiler will translate it to using the function calls. It is a matter of personal preference.

classList will be List<T> where as classList2 will be IQueryable<T>.

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
  • So, what is better to use? – Leojay Rull Jun 07 '18 at 01:56
  • @LeojayRull its up to you. – Daniel A. White Jun 07 '18 at 01:57
  • The LINQ syntax can provide more clarity when doing joins, simply because the equals operator keeps the join conditions located next to each other, whereas the extension method has to make use of lambda expressions for the key selectors, and that’s a lot of syntactic overhead/obfuscation for something relatively simple. The issue compounds when doing multiple joins, but the LINQ syntax remains pretty straightforward and compact even in that situation. That’s really the only situation I’d argue choosing one syntax over the other has any tangible impact (aside from social). – cwharris Jun 07 '18 at 03:55
0

First query is a Linq query. Since you added .ToList() to it, it will result in a List output

Second query is a Lambda expression, since it doesn't have any .ToList() in the end, it will result in IQueryable<T>. IQueryable<T> can be used to further add clauses without firing the query against the database.

Sunil
  • 3,404
  • 10
  • 23
  • 31
  • So, what is better to use? – Leojay Rull Jun 07 '18 at 01:56
  • Both of them finally gives the same output. It upto the individual learning and preferences. If the first looks easy to you, use that. I prefer first one because it looks very similar to a database query. – Sunil Jun 07 '18 at 03:43
0

It is a matter of developer preferences between the usage of Linq expression and Fluent dot notation approach.

But, both expressions will return an IQueryable<T> object as a preparation, up until you called the additional Linq extensions ToList, it will force to execute the SQL Statement back to the database.

I preferred to use the dot notation for the codes readability and by being the underlying method calls of other Linq expressions.

Hope this helps!

Mike
  • 161
  • 1
  • 1
  • 7
0

The following expression

from item in items select item

Is syntactic sugar for this expression

items.Select(item => item)

The syntax format is literally translated in to the extension method format at compile time.

However, in your example only one of those statements uses a ToList method, and therefore that method will enumerate or execute a query depending on whether items is an Enumerable or an IQueryable<>, respectively.

As for which is better to use, that’s mostly opinion based. For me, I find that the LINQ syntax can provide clarity when doing joins. I use the extension method syntax for most other queries. Play with both and see which one makes sense for you within the context a particular query. Often one syntax will provide more clarity to the intent of the query than the other. Other times it doesn’t make any difference.

While we’re on the topic, it’s worth noting that the LINQ syntax works by pattern matching against available extension methods. This means from x in xs select x won’t work if you haven’t imported an acceptable Select extension method, because the syntax gets replace with that method. On a more dangerous note, you could import an entirely separate set of extension methods to match with the LINQ syntax, so long as those method signatures match what is expected by the syntax. And that functionality is extendable to custom types, as well, but I haven’t looked in to that recently.

cwharris
  • 17,835
  • 4
  • 44
  • 64