EDIT: LINQ to Objects doesn’t behave how I’d expected it to. You may well be interested in the blog post I’ve just written about this…
They’re different in terms of what will be called – the first is equivalent to:
Collection.Where(x => x.Age == 10) .Where(x => x.Name == "Fido") .Where(x => x.Fat == true)
wheras the latter is equivalent to:
Collection.Where(x => x.Age == 10 && x.Name == "Fido" && x.Fat == true)
Now what difference that actually makes depends on the implementation of Where
being called. If it’s a SQL-based provider, I’d expect the two to end up creating the same SQL. If it’s in LINQ to Objects, the second will have fewer levels of indirection (there’ll be just two iterators involved instead of four). Whether those levels of indirection are significant in terms of speed is a different matter.
Typically I would use several where
clauses if they feel like they’re representing significantly different conditions (e.g. one is to do with one part of an object, and one is completely separate) and one where
clause when various conditions are closely related (e.g. a particular value is greater than a minimum and less than a maximum). Basically it’s worth considering readability before any slight performance difference.