如何将Linq扩展方法重写为委托？

Question

I asked this question, How do I return one-to-many records in a specific order with Dapper and multi-mapping?

and the answer is great, but I do not understand why it works. I don't understand because I don't know how to read it.

How can I rewrite this as delegates? I want to see the functions instead of the lambda, only so I can visualize it.

var groupedPosts = userposts.GroupBy(f => f.UserId, posts => posts, (k, v) =>
    new User()
    {
        UserId = k,
        Name = v.FirstOrDefault().Name,
        Posts = v.Select(f => new Post() { Id = f.Id, 
                                           Title= f.Title, 
                                           Content = f.Content})
    }).ToList();

I am mostly interested in this portion:

f => f.UserId, posts => posts,

and its relationship to

(k, v)

After that I can get it, I believe.

Answer 1

You mean you want to see something like this:

public static int fId(Foo f)
{
    return f.Id;
}

public static Foo fPosts(Foo f)
{
    return f;
}

public static User fSelect(int k, IEnumerable<Foo> v )
{
    return new User()
    {
        UserId = k,
        Name = v.FirstOrDefault().Name,
        Posts = v.Select(f => new Post()
        {
            Id = f.Id,
            Title = f.Title,
            Content = f.Content
         })
    };
}


var groupedPosts = userposts.GroupBy(fId, fPosts, fSelect);

Important is: fId returns int . And fPosts returns Foo . Because of this, parameters of the fSelect are int and IEnumerable<Foo> .

Answer 2

GroupBy is a extension method with several overloads here more about that. The overload that is used your example has the following reading.

The first argument ( f => f.UserId ) is a so called key selector - this will determ the key for each group.

The second argument( posts => posts ) is the value selector - this will determ what type of values will be contained in the groups

The third argument( (k, v) ) is called the result selector gives you one additional step before the group is materialized. This you can access the key ( UserId ) as first argument and a collection values (the values that will be contained in the group - all Posts for the UserId ) this gives you the ability to change/filter/project the result aditionally.

So for example if the third argument was omitted then the result will be group where the key is the UserId and the values in the Groups are the Posts , but with the third argument we can now access the UserId(the key) and the Posts(the values) and project them into a new type - User .

Answer 3

Read your answer as:

Group userposts by UserId; for each group, take all the posts for that id; now for each group, take the userId and all its posts and do ... with them.

Explanation

The expressions f => f.UserId , posts => posts look as if they're functions. But they're not. Well, they are, but kind of not ... well, this is confusing. What they are doing is filling in for some syntax that can't exist in the C# language.

The point is, how can you communicate to the GroupBy() method:

• What you want to group by: the key
• What you want to have in each group: The elements
• What (if any) further processing you want to do with the elements in each group. (This third bullet is a nice-to-have, but that's what the framework gives us)

It might be nice if C# could support this syntax:

var groupedPosts = userposts.GroupBy( UserId, this, (k, v) => {...});

but you can see at once that could never compile. You have to explain to the compiler that that UserId means the property of a UserPost of that name and that this is scoped to each userpost in turn. Before generics & lambdas, .net often solved this kind of thing by using strings for the fieldname:

var groupedPosts = userposts.GroupBy( "UserId", "", (k, v) => {...});

and then there would have to be some runtime reflection to turn that string into a propertyname & then get a value, & to realise that "" means the whole UserPost

But in C# we love strong-typing. And the lambda gives a cute-but-not-instantly-obvious way to "name" a property in a strong typed way:

f=> f.UserId

you see? Read this not so much as a function but as naming the property: "I want the UserId of each userpost"

Similarly, you can 'name' the whole entity:

f => f // means exactly the same as posts=>posts

(The function x=>x is called the identity function in computer science). And this is why it's hard to 'visualise' the delegate. The lambda is being used as a neat, strongly-typed way to identify a field or property.

[If that's crystal clear, let me now retract the 'it's not a function' statement. It is a function. Suppose you want to group by, not the UserId but by the name, and you want the grouping to be case-insensitive. Then you could use:

f=> f.Name.ToUpper()

So being a function is not just a way to get strong typing, it also gives more powerful options. You can do this in SQL too. ]

The final bit:

(k, v) => {....}

you then read as "for each userId & and set of posts for that userId, do ... with them". Notice that the names k & v are arbitrary parameter names and not so helpful here. I might have used:

(userid, postsforuserid) => {...}

Bringing it all together, you read

    userposts.GroupBy(
       userpost  =>  userpost.UserId, 
       userpost  =>  userpost,
       (userid, postsforuserid) => {...})

aloud as:

Group userposts by UserId; for each group, take all the posts for that id; now for each group, take the userId and all its posts and do ... with them

———————————————————————————————————

So, you see, seeing the delegate doesn't help much:

void Main()
{
    Del k = delegate (UserPost post) { return post.UserId; };
    Del v = delegate (UserPost post) { return post; };
}
class UserId { }
class UserPost { public UserId UserId { get; set; } }