c# - UI 层是否应该能够将 lambda 表达式传递到服务层而不是调用特定方法？

Question

我正在处理的 ASP.NET 项目有 3 个层；用户界面、BLL 和 DAL。我想知道 UI 是否可以接受将 lambda 表达式传递给 BLL，或者 UI 是否应该传递参数并且 Service 方法应该使用这些参数来构造 lambda 表达式？这是一个显示两种场景的示例类。

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);
    }
}

对于上面的类，UI 调用下面的方法是否可以接受:

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

还是应该只允许调用 GetJob(int jobID)？

这是一个简单的例子，我的问题是一般性的，UI 层是否应该能够将 lambda 表达式传递到服务层而不是调用特定的方法？

Answer 1

这是根据情况判断的调用。传递这样的谓词不一定错误。不过，我认为它应该被视为轻微的难闻气味。

如果传入 lambda 表达式可以让您将 6 个方法减少到 1 个，那么这可能是一个很好的举措。另一方面，如果您可以轻松地传入一个简单类型，那么 lambda 语法就是一种不必要的复杂化。

在上面的例子中，在不知道上下文的情况下，我的偏好是使用一个简单的整数参数。通常应该有一个基本方法可以通过它的 ID 获取记录。也许还有一两个在您的应用程序中重复使用的其他此类方法。然后可能一个采用 lambda 的通用方法。

您还应该考虑一些人建议的规则:您在您的 UI 和业务层之间没有任何带有 lambda 指定谓词的方法。 (有些人有理由相信，您的存储库甚至不应该有这样的方法!)我不认为这应该是一条铁律，但有充分的理由。您的业​​务层和数据层应防止危险查询的发生。如果您允许传入 lambda 表达式，那么 UI 层的初级开发人员很容易指定可以真正控制您的数据库的查询。 (例如，他们将对非索引字段进行大量查询，和/或使用 LINQ-to-objects 对结果集进行过滤，但没有意识到这是多么低效。)

与许多其他良好做法一样，这在一定程度上取决于范围。在我最近的大型应用程序中，我没有将 lambda 语法从 UI 层传递到业​​务层。我的计划是在业务层投入大量资金，让它变得非常智能。它具有具有简单类型的所有需要​​的方法。事实上，它通常通过简单的域对象属性为您提供所需的内容，根本没有任何参数。我的界面确保 UI 只能导致高效查询发生，可能只是 UI 层中的次要 LINQ-to-Objects 谓词。 (这甚至适用于“搜索”页面。我的业务层接受具有受限可能性的条件对象，并确保高效查询。)

现在，您说的是“层”，而不是“层”。所以这些都在同一个程序集中？ lambda 的另一个缺点是它们(目前)难以序列化。因此，如果您不得不分开等级，您会后悔的。