javascript - 使用 OData 和 IQueryable 的风险

Question

我看过很多关于制作 SPA(单页应用程序)的教程，其中许多教程使用外部库(例如 breezejs 和 jaydatajs)来获得自动化数据服务层。

这些库希望我公开一个它们可以查询的 IQueryable 对象。

我的问题是，从服务器公开 IQueryable 有哪些风险？我想知道使用这些 js 库制作这个快捷方式是否值得，或者我应该在服务器中公开我自己的函数并在客户端中自己实现数据服务。

问题是，在公开 Iqueryable 时，我可以使用 breezejs，例如，使用类似 linq 的语法创建用于过滤和分页的查询。如果我不使用它，我将不得不在服务器中实现这些过滤和分页功能。并在 javascript 中实现对它们的调用。

我希望我是清楚的:-)

Answer 1

在公开 IQueryable 时，我尝试做一件事...确保您不公开您的 EF 样式对象，始终确保您有某种 View 模型位于您可以控制的顶部。

举个例子，假设你的数据库有 User 和 UserSecrets

public class User
{
    public long UserId { get; set; }
    public string Name { get; set; }
    public virtual ICollection<UserSecret> UserSecrets { get; set; }
}

public class UserSecret
{
    public long UserSecretId { get; set; }
    public long UserId { get; set; }
    public string Secret { get; set; }
}

如果你暴露IQueryable<User>您也可以轻松提取 UserSecrets

www.blah.com/users?$expand=UserSecrets

而是公开一个 UserViewModel或类似的东西

public class UserViewModel
{
     public string Name { get; set; }
} 

你可以暴露IQueryable<UserViewModel>通过以下方式:

return dbContext.Users.Select(u => new UserViewModel { Name = u.Name })

很棒的是，这仍然是 IQueryable - 你仍然可以过滤等，它仍然会在数据库级别执行，但你可以控制可以提取的数据(在这种情况下 UserSecret 不再可访问)。

当然，您也可以应用自己的过滤器，这样您就可以避免用户无法访问他们不允许的数据:

return dbContext.Users.Where(u => ...).Select(u => new UserViewModel { Name = u.Name })