Question

The ASP.NET project I am working on has 3 layers; UI, BLL, and DAL. I wanted to know if it was acceptable for the UI to pass a lambda expression to the BLL, or if the UI should pass parameters and the Service method should use those parameters to construct the lambda expression? Here is an example class showing both senarios.

public class JobService 
{
    IRepository<Job> _repository;

    public JobService(IRepository<Job> repository) 
    {
        _repository = repository;
    }

    public Job GetJob(int jobID)
    {
        return _repository.Get(x => x.JobID == jobID).FirstOrDefault();
    }

    public IEnumerable<Job> Get(Expression<Func<Job, bool>> predicate)
    {
        return _repository.Get(predicate);
    }
}

For the above class is it acceptable for the UI to call the following:

JobService jobService = new JobService(new Repository<Job>());
Job job = jobService.Get(x => x.JobID == 1).FirstOrDefault();

or should it only be allowed to call GetJob(int jobID)?

This is a simple example, and my question is in general, should the UI layer be able to pass lambda expressions into the service layer instead of calling a specific method?

Answer 1

This is a judgement call based on the situation. It’s not necessarily wrong to pass in a predicate like this. I think it should be considered a minor bad smell though.

If the passing in of a lambda expression allows you to reduce 6 methods down to 1, then it might be a good move. On the other hand, if you can just as easily pass in a simple type, then lambda syntax is a needless complication.

In the above example, not knowing the context, my preference would be to use a simple integer parameter. There should usually be a basic method that just gets a record by it’s ID. And maybe one or two other such methods that are repeatedly used through your application. And then maybe a general purpose method that takes a lambda.

You should also consider what some would suggest should be a rule: that you not have any methods with lambda-specified predicates between your UI and your business layer. (And some believe, with reason, that your repositories shouldn’t even have such methods!) I don’t believe this should be an iron-clad rule, but there’s good reasons for it. Your business and data layers, between them, should keep dangerous queries from happening. If you allow the passing in of lambdas, it’s very easy for a junior developer in the UI layer to specify queries that could really hose your database. (For example, they’ll do huge queries against non-indexed fields, and/or filter against the resultset using LINQ-to-objects, and not realize how inefficient that is.)

Like many other good practices, this will depend somewhat on scope. In my recent large application, I have no passing of lambda syntax from the UI layer to the business layer. My plan was to invest heavily in the business layer, to make it very smart. It has all the needed methods with simple types. In fact, it typically gives you what you need through simple domain object properties, with no parameters at all. My interface assures that the UI can only cause efficient queries to happen, with perhaps just minor LINQ-to-Objects predicates in the UI layer. (This goes even for “search” pages. My business layer accepts a criteria object with constrained possibilities, and ensures an efficient query.)

Now, you said “layers”, rather than “tiers”. So these are all in the same assembly? Another disadvantage of lambda is they’re (currently) difficult to serialize. So you’d regret them if you had to separate your tiers.