使用breezejs在javascript中获取查询信息不是很危险吗？

Question

刚开始使用breeze.js，因为编码时间明显增加，即直接在Javascript中管理从服务器访问模型数据（我在这里是新手，所以很明显没有！）。

过去我使用股票ajax调用来获取/发布数据到服务器，过去我使用了一些不同的客户端工具来查询本地数据，例如jLinq 。

我的问题是这个。在Javascript中拥有基本完整的模型查询访问权限不是很危险吗？我必须遗漏一些东西，因为它看起来像是一个经过深思熟虑的工具。在过去，我至少控制了可以通过后端查询过程发送给客户端的内容，并再次使用类似jLinq等的东西我可以过滤数据等。我也可以理解权衡可能获得直接查询/没有重复的本地模型问题，所以只要有人能提供一些见解吗？

谢谢！

修改 显然我不是唯一一个，但是我猜测有一个合理的反应 - 可能限制使用DTO方法或其他东西要求的数据？ The other question posted is here

Answer 1

公开完整的商业模式可能很危险。允许无限制地查询您希望向客户端公开的模型部分可能是危险的。无论您提供易于查询的API还是难以查询的API，都是如此。

这就是为什么我们的团队小心我们如何构建我们的服务。

您应该只公开客户端应用所需的类型。如果要限制对类型的授权实例的访问，可以仔细编写规定的不可查询的服务方法。微风可以称他们为好。您不必为每个请求使用Breeze查询工具。您仍将受益于缓存，相关实体导航，更改跟踪，验证，保存捆绑，缓存查询，离线支持。

重复：您的服务方法不必返回IQueryable。即使它们确实返回IQueryable，您也可以轻松编写服务方法，将查询结果限制为用户有权查看的实体。

幸运的是，您可以在同一服务或协作服务中混合使用这两种方法。

Breeze为您提供选择。你应该明智地行使这些选择。去那里设计您的服务以满足您的要求。

Answer 2

在这个意义上，Breeze并不意味着 你的业务逻辑。请记住经验法则，如果您在Javascript中执行某些操作，任何人都可以执行此操作，您应该根据需要限制自己的服务数据的可见性。

换句话说，如果您打算公开显示数据，它对您很有用。但只暴露您喜欢暴露的实体并允许任何人查询;另一种看待它的方法是，您的API成为您网站的公共API（但不是您宣传并告诉所有人使用的API）。

我个人并不是以这种方式做事的粉丝，因为在后端实现的架构上创建了依赖关系。如果我想对我的数据库表进行更改，我现在必须考虑我的Javascript。我也缺乏集成和单元测试。

但是，如果您希望在非敏感数据上快速构建网站功能而无需构建服务方法及其各种实现层，则可以使用它。

Answer 3

当您公开元数据时怎么样？这不是危险的。恕我直言，从DbContext公开元数据是不安全的。我知道你可以在客户端上构建元数据，但重点是尽可能快地做事（如果安全的话）。