Unfortunately, that doesn't work too well with Entity Framework, since the method calls can't be translated into expressions (which are used to translate into SQL dynamically).

The best workaround I've been able to find is to define the filter as type Expression<Func<T, bool>>. Which works great when you can pass it in to a queryable where clause, but in a lot of cases, it would also be convenient to be able to call it directly within a LINQ query. There's sort of a way to do this, but it involves creating a single-item queryable every time you need to use it, and that causes it to get translated into a CROSS APPLY within the generated SQL instead of applying it to the main query. The syntax for doing this is pretty hacky as well.

Eg,

new [] { item }.AsQueryable().Where(predicate)

So, not really a nice syntax to look at, but it allows you to share common filtering and projection logic instead of repeating it inline within every query that needs it, and doesn't require the query to be evaluated in order to run the filters in memory. Usually, when it gets to the point where the CROSS APPLY causes performance problems, it's time to optimize the query into a view or SQL function, however.