使用breezejs在javascript中获取查询信息不是很危险吗？ [英] Isn't it dangerous to have query information in javascript using breezejs?

问题描述

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

Just starting to play with breeze.js because of the obvious gains in coding time, i.e. managing to access model data from the server direct within Javascript (I am a newbie here, so obviously bare with!).

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

In the past I have used the stock ajax calls to get/post data to the server, and I have used a few different client tools in the past to provide some help in querying local data, such as jLinq.

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

My question is this. Isn't it dangerous to have essentially full model query access in Javascript? I must be missing something because it looks like a really well thought through tool. In the past I have at least controlled what can be sent to the client via the backend query process, and again using something like jLinq etc I could filter the data etc. I can also understand the trade-off perhaps with gaining the direct query/none-duplicating local model problem, so just if anyone could provide some insight to this?

谢谢！

编辑
显然我不是唯一一个，但我猜测有一个合理的回应 - 可能限制使用DTO方法或其他方式请求的数据？ 发布的其他问题在这里

推荐答案

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

It can be dangerous to expose the full business model. It can be dangerous to allow unrestrained querying of even that part of the model that you want to expose to the client. This is true whether you offer an easy-to-query API or one that is difficult to query.

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

That's why our teams are careful about how we construct our services.

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

You should only expose types that your client app needs. If you want to limit access to authorized instances of a type, you can write carefully prescribed non-queryable service methods. Breeze can call them just fine. You don't have to use the Breeze query facilities for every request. You'll still benefit from the caching, related-entity-navigation, change-tracking, validation, save-bundling, cache-querying, offline support.

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

Repeat: your service methods don't have to return IQueryable. Even when they do return IQueryable, you can easily write the service method to constrain the query results to just those entities the user is authorized to see.

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

Fortunately, you can blend the two approaches in the same service or in collaborating services.

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

Breeze gives you choices. It's up to you to exercise those choices wisely. Go out there and design your services to fit your requirements.

这篇关于使用breezejs在javascript中获取查询信息不是很危险吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！