Resolved LINQ to get list of objects that contain an exact list in a complex structure

[ColinMay80]

This is a silly example but hope you get the idea.

Say I have a list of Persons, that contains a list of jeans which contains a list of features. In class, Feature, we have a Name property that is a FeatureType.

How do I check (and return the filtered list) and for example I have a list of 5 persons each having multiple pairs of jeans and 3 persons have jeans that match the criteria of having jeans that have a feature name of TORN and LOOSE?

class Person
{
   List<Jean> Jeans
}

class Jean
{
     List<Feature> Features
}

class Feature
{
    string ProductCode
    FeatureType Name
}

public enum FeatureType 
{
    TORN,
    SKINNY,
    LOOSE,
    TAPERED
}

 

[jmcilhinney]

I don't disagree. I just think the OP was misguided from the start, trying to avoid nested loops for performance reasons. I'm a big fan of LINQ myself but I see a lot of people trying to use it without understanding it or, worse, not understanding the "conventional" code it would replace. That's probably our fault to a degree, as I see a lot of people recommending LINQ solutions to beginners who obviously know nothing about it. I'm guilty of that myself. Ideally, I would recommend that no one writes LINQ code where they don't understand what the alternative would be. If you don't understand the alternative then you don't understand the logic your LINQ code is supposed to implement.

 

[ColinMay80]

Thanks Skydiver for the benchmarking and everyone for the comments and recommended solutions. Deep down I know the naive approach can be or is faster. I do understand the alternative but appreciate Linq for the readability and declarative nature (ie. saying what I want rather reading through lines of code detailing how to get what I want). From my experience, nano seconds isn't going to impact the applications I work with but long lines of not so easy to read code will my developer time.

 

[Skydiver]

I would rather read for loops and recursive code than read SQL with CTEs. Different strokes for different folks.