One of the cool things I discovered while getting to grips with LINQ is that you can chain LINQ queries together. This helps when trying to follow the Don't Repeat Yourself (DRY) approach to design, which I'm sure we all do.

While using DataSets and SQL/Stored Procedures in ASP.NET projects I was finding myself repeating the same SQL over and over. Any change to the column in any of the tables would likely mean a change to all the queries I had stored. Ergh.

As an example, let's say you have your zoo and its animals. If you want a list of animals that are viewable by the visiting public you might have a query like this:

public IEnumerable<Animal> GetViewableAnimals()
{
    return zoo.Animals.Where(
               a => a.Alive 
               && !a.Sick 
               && a.DepartureDate == null
         ).OrderBy(a => a.Name);
}

Not a great real-world example, but you get the idea - there's a base logic for what set of animals any other list should ever derive from.

Now, let's say you want get animals of a certain types (monkeys?). You might write another method, like so:

public IEnumerable<Animal> GetAnimalsByType(AnimalType type)
{
        return zoo.Animals.Where(
                a => a.Alive
                && !a.Sick
                && a.DepartureDate == null
                && a.Type = (int)type
        ).OrderBy(a => a.Name);
}

But, wait. You've repeated yourself! What if the logic by which you decide if an animal is "viewable" changes (say, you let the public see sick animals)!? You need to update all methods.

Well, you could instead have each method return an IQueryable object and chain them together. Like so:

public IQueryable<Animal> GetAnimalsByType(AnimalType type)
{
    return GetViewableAnimals()
                      .Where(a => a.Type == (int)type)
                      .OrderBy(a => a.DateOfBirth);
}
    
public IQueryable<Animal> GetViewableAnimals()
{
    return zoo.Animals.Where(
                a => a.Alive 
                && !a.Sick 
                && a.DepartureDate == null
          ).OrderBy(a => a.Name);
}

Notice how the "by type" method first gets the "base" query from the other method and then appends an extra clause to the "where" part of the statement.

Note that it's not until you try to access the data in the IQueryable class that it performs the SQL query. So, the above does not perform two SQL queries. Just one!

A fuller example would be the following example of a repository class:

public class AnimalRepository
{
    ZooDataClasesContext zoo = new ZooDataClasesContext();

    public IQueryable<Animal> Search(string query)
    {
        return GetViewableAnimals()
                .Where(a => a.Name.Contains(query))
                .OrderBy(a => a.Name);
    }
    
    public IQueryable<Animal> GetAnimalsByType(Animal.Type type)
    {
        return GetViewableAnimals()
                .Where(a => a.type == (int)type)
                .OrderBy(a => a.DateOfBirth);
    }

    public IQueryable<Animal> GetAnimalsByName(string name)
    {
        return GetViewableAnimals()
                .Where(a => a.Name == name)
                .OrderBy(m => m.DateOfBirth);
    }
    
    public IQueryable<Animal> GetAnimalsByType(AnimalType type)
    {
        return GetViewableAnimals()
                .Where(a => a.Type == (int)type)
                .OrderBy(a => a.DateOfBirth);
    }
    
    public IQueryable<Animal> GetViewableAnimals()
    {
        return zoo.Animals.Where(
                    a => a.Alive 
                    && !a.Sick 
                    && a.DepartureDate == null
                ).OrderBy(a => a.Name);
    }
}

There might be other or better ways to do this, but, for now, it's my preferred approach. I came up with the above while working on an app that has a fairly complex set of rules about what the base set of viewable rows are for the current user. Chaining queries like this means I only have to write this logic once.