Пользовательские классы помощника HTML нарушают модель ASP.NET MVC?

Поскольку компилятор на самом деле корректен: вы пытаетесь выполнить >= между лямбда-числом и числом:

Expression.GreaterThanOrEqual(selector /* this is a lambda*/, Expression.Constant(...))

Я действительно думаю, что вы должны стараться избегать вложенных лямбд как можно больше , Лучший способ добиться этого (imho) - заменить выражения параметров во второй лямбде соответствующими параметрами первой лямбды, а затем объединить тела двух лямбда-выражений следующим образом:

    public static Expression<Func<T, bool>> And<T>(this Expression<Func<T, bool>> expr1, Expression<Func<T, bool>> expr2)
    {
        var replacer = new ParameterReplaceVisitor(expr2.Parameters[0], expr1.Parameters[0]);
        return Expression.Lambda<Func<T, bool>>(Expression.AndAlso(expr1.Body, replacer.Visit(expr2.Body)),
            expr1.Parameters[0]);
    }

    private class ParameterReplaceVisitor : ExpressionVisitor
    {
        private ParameterExpression _oldParameter;
        private ParameterExpression _newParameter;

        public ParameterReplaceVisitor(ParameterExpression oldParameter, ParameterExpression newParameter)
        {
            _oldParameter = oldParameter;
            _newParameter = newParameter;
        }

        protected override Expression VisitParameter(ParameterExpression node)
        {
            if (node == _oldParameter)
            {
                return _newParameter;
            }
            else
            {
                return node;
            }
        }
    }

[116 ] Редактировать: Преимущество этого решения, которое позволяет избежать лямбда-выражений, состоит в том, что реализация Linq, скорее всего, поймет, что вы хотели сделать, и переведет, например: в SQL. Я не уверен, что, например, EF попытается перевести вызовы лямбда-выражений в SQL, потому что вряд ли это действительно работает.