使用OData和IQueryable的风险

Question

我已经看过许多关于制作SPA(单页面应用程序)的教程,其中许多都使用了外部库,如breezejs和jaydatajs,以获得自动数据服务层.

这些库期望我将公开他们可以查询的IQueryable对象.

我的问题是,从服务器中暴露出IQueryable的风险是什么？我想知道如果用这些js库制作这个快捷方式值得,或者我应该在服务器中公开我自己的函数并在客户端自己实现dataservice.

问题是,当暴露Iqueryable时,我可以使用breezejs来创建用于使用linq like语法进行过滤和分页的查询.如果我不使用它,我将不得不在服务器中实现这些过滤和分页功能.并在javascript中实现对它们的调用.

我希望我很清楚:-)

Answer 1

在暴露IQueryable时我尝试做一件事......确保你没有暴露你的EF风格对象,总是确保你有一个可以控制的顶部的视图模型.

举个例子,假设你的数据库有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 })