想象一下，您将EntityFramework用作ORM，它们都包装在单独的DAL类库中。
您在另一个“公共”类库中具有以下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();
}
}
并且所有作品都矮胖。
。
但是随后您需要向服务添加新方法来处理其他查询（例如，年龄范围内的用户）。
然后另一个。
还有一个
。
不久之后，您开始思考
如果您可以提供可以想到的任何查询，那不是很好吗
到达服务层，它将获得相关数据和
将其返回给您，而不必显式定义每个可能的对象
作为一种独特的方法进行查询，与SL已经存在的方式几乎相同
用DAL做的吗？
所以问题是：
这是否有可能在SL内实现安全，同时
保持松散耦合？
。
我已经读过，使用IQueryable可能导致类似以下情况的灾难：
q.Where(x=>{Console.WriteLine("fail");return true;});
但是我对使用ORM和服务层还很陌生，因此自然会在寻找“最佳实践”和“已知陷阱”，同时还希望保持我的代码整洁。
最佳答案
听起来您正在将业务层逻辑泄漏到表示层中。
如评论中所述，确定表示层应显示的确切数据集实际上是业务逻辑。
您的UI上可能有一些字段，这些字段使用户能够选择要显示的特定年龄范围，这是完全有效的，但是表示层应该负责将这些值上推到服务层并提供返回的数据以友好/预期的方式添加到实际的用户界面。
基于这些值的数据实际搜索/拟合应在服务层/业务层内完成。
关于c# - “安全”的可查询服务层设计？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/30776567/