HELP - with X# syntax - Relay Command ...

[NickFriend]

Hi Frank,

In the context of Entity Framework it's pretty much a requirement if you're going to use EF in the way it's intended.

Elsewhere in reality it's personal preference, and almost certainly slower (marginally) than doing a foreach loop. However the thing about Linq is that you can do so much more than simply iterate through lists.

Say you want to sum a value

Code: Select all

decimal total = 0M;
foreach (OrderItem item in orderitemlist)
{
  if (item.OrderId == requiredid)
    total += item.TotalValue;
}

decimal total = orderitemlist.Where(i => i.OrderId == requiredid).Select(v => v.TotalValue).Sum();

Or get a new list of objects matching some criteria

Code: Select all

List<OrderItem> selecteditems = new List<OrderItem>();
foreach (OrderItem item in orderitemlist)
{
  if (item.OrderId == requiredid)
    selecteditems.Add(item);
}

List<OrderItem> selecteditems = orderitemlist.Where(i => i.OrderId == requiredid).ToList();

Once you get used to the syntax it becomes a very natural way of doing just about anything you want with collections, and the method chaining is very flexible and powerful. I strongly recommend you take the time to get used to it.

Nick

[Phil Hepburn]

Frank,

I totally agree with Nick, and even more so since I had years at using SQL Server stuff for a living. I got used to not looping through rows and columns.

However, I suspect strongly that the LINQ and query syntax ends up as for loops in the code behind, and maybe after compilation runs almost as quick as the raw Foreach code.

Microsoft often seems to reuse its software technology, by building things up in layers of code and code design. I would be VERY surprised if Entity Framework does not heavily use ADO.NET for example.

I used ADO.NET a lot, and to good effect - BUT - it is awful to have to code in it directly, EF is way, way, better. So if the ADO.NET stuff is still there then thanks to MS for hiding it ;-0)

The nice thing about what Nick and I are doing, is that we are essentially doing the same thing, but I prefer the T-SQL style query code, and Nick the Extension Method. They live happily together, and Nick can still run away from his nasty threatening SQL script !!!

I am working on some nice examples which I hope to post later.

In .NET, data is objects and objects make up collections. LINQ was designed to allow us data guys to process collections, its as simple as that.

Speak on this subject again later, when I have done my samples.
Cheers,
Phil.

[Frank Maraite]

Nick, Phil,

thanks for your answer. I'll try as soon as possible.

Frank

[Phil Hepburn]

Hi Nick, Frank, and all,

Here is some of the X# samples I promised, along the lines that Nick suggested.

We will see some LINQ and Extension method syntax.

Checkout image _01 below :-

PearsSum_01.jpg (32.07 KiB) Viewed 306 times

This is some simple code to add together (sum) each and every identity value of the Product objects in the collection. As you can see the full total is 105.

Now let us make a small sub-list of IDs - those of 3,5 and 9 :-

PearsSum_02.jpg (52 KiB) Viewed 306 times

With the addition of the WHERE clause we can filter out from the whole set of identities, those included in the small sub set (or sub-list).

Note we are using 'Contains' and a similar approach exists in T-SQL script. The code is quite readable I feel.

So what is the sum of all those IDs that we have so far ignored, or filtered out ?

Well, here is one way to get an answer :-

PearsSum_03.jpg (55.31 KiB) Viewed 306 times

In the code of the above image we are stating in the WHERE clause that the identity of the Product item in focus is NOT contained in our short list, or small set.

Now lets look at a convenient and very readable way of generating this 'other' set, all those IDs which are not 3,5, or 9. Check this out below :-

PearsSum_04.jpg (70.13 KiB) Viewed 306 times

Line 149 shows some 'set algebra' in use, we often forget this very useful approach when dealing with collects, which after all are sets of objects. So lets think 'SET'.

One set 'taken' from another is an 'Except' in extension method use.

So now we can even do a double negative - see below for some 'fun' coding :-

PearsSum_05.jpg (37.52 KiB) Viewed 306 times

Checkout line 154 !

Finally, we will look at adding sets together before we do our WHERE clause. Lets try some UNION work :-

PearsSum_06.jpg (56.38 KiB) Viewed 306 times

And if we are then to use the joined up set as an ID check-list we can see this code at work :-

PearsSum_07.jpg (89.06 KiB) Viewed 306 times

Okay then folks, lets hope that made some sense to some of you.

Note I have used the 'query' style of coding, but that used by Nick (extension method coding extensively) is still very similar in many ways. And we can't express all code in query syntax either, so we have to know how to use some EMs in our code.

Fingers crossed,
Phil.