C# IEnumerable Return Changes after Function Parameter Changes-CodePudding

I was writing unit tests to compare an original response to a filtered response using a request object as a parameter. In doing so I noticed that if I change the request object after getting a response the IEnumerable list will change - As I type this, my thinking is that because it is an IEnumerable with LINQ, the request.Filter property is a reference in the LINQ query, which is what causes this behavior. If I converted this to a list instead of an IEnumerable, I suspect the behavior would go away because the .ToList() will evaluate the LINQ expressions instead of deferring. Is that the case?

public class VendorResponse {
    public IEnumerable<string> Vendors { get; set; }
}

var request = new VendorRequest() {
    Filter = ""
};

var response = await _service.GetVendors(request);

int vendorCount = response.Vendors.Count(); // 20
request.Filter = "at&t";
int newCount = response.Vendors.Count(); // 17

public async Task<VendorResponse> GetVendors(VendorRequest request)
{
    var vendors = await _dataService.GetVendors();
    return new VendorResponse {
        Vendors = vendors.Where(v => v.IndexOf(request.Filter) >= 0)
    }
}

CodePudding user response：

If deferred execution is preferable, you can capture the current state of request.Filter with a local variable and use that in the Where predicate

public async Task<VendorResponse> GetVendors(VendorRequest request)
{
    var filter = request.Filter;

    var vendors = await _dataService.GetVendors();

    return new VendorResponse {
        Vendors = vendors.Where(v => v.IndexOf(filter) >= 0)
    }
}

CodePudding user response：

Yes!

This is an example of deferred execution of an IEnumerable, which just encapsulates a query on some data without encapsulating the result of that query.

An IEnumerable can be enumerated (via its IEnumerator), and "knows" how to enumerate the query it encapsulates, but this will not actually happen until something executes the enumeration.

In your case the enumeration is executed by the call to .Count() which needs to know how many items are in the result of the query. The enumeration occurs every time you call .Count(), so changing the filter between the two invocations leads to you getting two different results.

As you have correctly deduced, calling .ToList() and capturing the result in a variable before performing any further operations would lead to you capturing the resulting data rather than the query, and so lead to both counts having the same value.

Try this out yourself. In future, be sure to force the evaluation of the enumerable before passing to other queries, or returning out to unknown code, otherwise you or your users will encounter unexpected behaviour and possible performance issues.

Hope this helps :)

Edit 1: As Moho has pointed out, and you have also alluded to in your original post, this is also a result of the request.Filter being captured by the IEnumerable as a reference type. If you can capture the value and pass this in instead, the result of the IEnumerable will no longer be modified by changing the filter.