User987 User987 - 8 months ago 33
ASP.NET (C#) Question

Linq group by ID and then sum the ID itself (key)

I have two lists which are basically of the same class type like following:

public class TransactionsTabResults
public string ItemID { get; set; }
public string Title { get; set; }

public string ItemImage { get; set; }

public float ItemPrice { get; set; }

public int PageViews { get; set; }

public float AveragePrice { get; set; }

public int TotalSoldItems { get; set; }

public float TotalRevenuePerItem { get; set; }


The list #1 is the TransactionsData and it contains 250 items whose only initialized properties are: ItemID, Title and ItemPrice;

The ItemID itself repeats several times inside the first List. Now what I'm trying to achieve in second list(transactionsList) is following:

var _transactionsList = TransactionsData.GroupBy(x => x.ItemID).Select(pr => new TransactionsTabResults {
ItemID = pr.Key,
Title = pr.Select(x => x.Title).FirstOrDefault(),
// here goes total sales of the item => sum of the groupby function by ItemID
// here goes the average selling price => sum above divided by price of the item
TotalRevenuePerItem= pr.Sum(y=>y.ItemPrice)

As you can see I'm trying to group all the items inside the list by ItemID and then sum the the key to get the amount of sales per item (if you guys understand what I'm trying to achieve) - the amount of times that the ID repeats itself is the amount of sales that item has...

Can someone help me out to figure this out?

Edit: I need to get the key value (The parameter I'm grouping by the whole list) - value/amount of how many times ItemID repeats itself in #1 list...

Answer Source

You don't want to "sum the IDs" - you just need the average of the prices, which you can get using the Average method. If you want the count, just call Count():

AverageRevenuePerItem = pr.Average(y => y.ItemPrice),
TotalSalesPerItem = pr.Count()

Summing IDs - or performing any other kind of arithmetic with them - is always a bad idea. If they are generated in a monotonic order then comparing them (in terms of higher/lower for later/earlier) can be useful, but other than that you should treat them as values which can only be compared for equality.

Separately, I'd strongly advise you to revise your data model. Currently you've got a mixture of "this is a single sale" and "this is an aggregate of sales". That's just going to lead to confusion. Likewise it's not clear that you need a title in the transaction - that should be in a separate table/model describing the items. So I can see you having something like:



  AverageRevenue // Redundant really, as it's just total revenue / transaction count

I don't know where page views fits into that model, if at all.