c# - "safe"可查询服务层设计？

Question

假设您使用 EntityFramework 作为 ORM，所有这些都封装在一个单独的 DAL 类库中。

您在另一个“公共(public)”类库中有以下 POCO 对象，它在您的 DAL、SL 和表示层之间很好地共享:

public class User
{
   public int Id { get; set;}
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public string Email { get; set; }
   public int Age { get; set; }
   public Gender Gender { get; set; }
}

然后您在 SL 中实现以下内容:

public interface IUserService
{
   User GetById(int u);
   List<User> GetByLastName(string s);
}

public class UserService : IUserService
{
   private MyContext _myContext;
   public UserService(MyContext myContext = null)
   {
      _myContext = myContext ?? new MyContext();
   }
   public User GetById(int userId)
   {
      return _myContext.Users.FirstOrDefault(u=>u.Id == userId);
   }

   public List<User> GetByLastName(string lastName)
   {
      return _myContext.Users.Where(u=>u.LastName == lastName).ToList();
   }
}

所有的作品都很棒。
.
但是随后您需要向服务添加一个新方法来处理不同的查询(例如，属于某个年龄段的用户)。
然后是另一个。
还有一个……
.
不久，你开始思考

Wouldn't it be nice if you could provide any query you can think of through to the service layer, and it would get the relevant data and return it for you, without having to explicitly define each possibly query as a distinct method, much in the same way the SL is already doing with the DAL?

所以问题是:

Is this possible to achieve SAFELY within a SL, whilst still maintaining loose coupling? .
I've read that using IQueryable can lead to disaster with things like:

q.Where(x=>{Console.WriteLine("fail");return true;});

但我对 ORM 和服务层的使用还相当陌生，所以自然会寻找“最佳实践”和“已知陷阱”，同时也希望保持我的代码整洁。

Answer 1

听起来您正在将业务层逻辑泄漏到表示层中。

如评论中所述，确定应由表示层显示的确切数据集实际上是业务逻辑。您的 UI 上可能有一些字段，使用户能够选择要显示的特定年龄范围，这是完全有效的，但是表示层应该负责将这些值推送到服务层并提供它返回的数据以友好/预期的方式显示到实际用户界面。

基于这些值的实际数据搜索/过滤应该在服务层/业务层内完成。