Func
`Func<>` is a lambda expression. A delegate. A pointer to a method. Runtime engine can not “look” inside `Func<>`, it can only execute `Func<>`.
Example usage:
Func<int> haveFunc = () => 15; // return 15
Expression Func
`Expression<Func<>>` is an expression tree. It’s a lambda expression in form of tree data structure. It only hold metadata or information and composition of the contained lambda expression. Runtime engine can look “inside” `Expression<Func<>>` and translate it to other statement you need.
Example usage:
Expression<Func<int>> notMuchFunc = () => 25;
Why is it important ?
Misuse of this could be cause compile error or in the case of EF, a performance hit.
Compile Error Example
Linq has few methods that take `Func<>` or `Expression<Func<>>` parameter, for example `Where` extension method, as seen in signature below.
System.Linq.Enumerable
public static IEnumerable<TSource> Where<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate);
System.Linq.Queryable
public static IQueryable<TSource> Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, bool>> predicate);
Depend on parameter type we pass in, compiler know which extension method to call.
In the code below, ProcessUsers3 throw compiler error. Because we pass in `Expression<Func<>>`, compiler think we are calling `Where` extension method which accept `IQueryable<>` but `this.GetUserNames()` return `IEnumerable<>`.
The workaround is to convert `IEnumerable<>` to `IQueryable<>` using `.AsQueryable()` as can be seen on ProcessUsers4.
public IEnumerable<string> GetUserNames()
{
return new[] { "user1", "user2" };
}
public void ProcessUsers()
{
// Return type IEnumerable<string>
var result = this.GetUserNames()
.Where((item) => !string.IsNullOrEmpty(item));
}
public void ProcessUsers2()
{
// Return type IEnumerable<string>
Func<string, bool> predicate = (item) => !string.IsNullOrEmpty(item);
var result = this.GetUserNames()
.Where(predicate);
}
public void ProcessUsers3()
{
// Compile error
// We pass in Expression<Func<>> to Where extension method, compiler think we are calling the Where extension method for IQueryable<> - this.GetUserNames() return IEnumerable<>
Expression<Func<string, bool>> predicate = (item) => !string.IsNullOrEmpty(item);
var result = this.GetUserNames()
.Where(predicate);
}
public void ProcessUsers4()
{
Expression<Func<string, bool>> predicate = (item) => !string.IsNullOrEmpty(item);
// Return type IQueryable<string>
var result = this.GetUserNames()
.AsQueryable()
.Where(predicate);
}
Performance Hit Example
In the code below, both methods are legal, compile without error and run without error.
On GetAppConfigurations1, we query EF context by passing `Func<>`, a lambda expression. Because the context can not “look” inside the lambda expression (it can only execute it), Linq would get all AppConfiguration and run `Func<>` on each record, which increase load time.
On GetAppConfigurations2, we query EF context by passing `Expression<Func<>>`, an expression tree. It allow Linq to “look” inside the expression tree, read its metadata and composition than figure out the best and most perfomant way to query AppConfiguration with filter condition we specified.
public IEnumerable<AppConfiguration> GetAppConfigurations1()
{
Func<AppConfiguration, bool> filter = (config) => config.Id == 1;
using (var context = new QCEntities())
{
var result = context.AppConfiguration.Where(filter);
return result;
}
}
public IEnumerable<AppConfiguration> GetAppConfigurations2()
{
System.Linq.Expressions.Expression<Func<AppConfiguration, bool>> filter = (config) => config.Id == 1;
using (var context = new QCEntities())
{
var result = context.AppConfiguration.Where(filter);
return result;
}
}
References
Stackoverflow
Like this:
Like Loading...
