我们正在考虑breeze js来构建企业应用程序。
微风的真棒是我们可以直接从客户端浏览器执行查询。这允许基于用户输入构造动态查询而不加载不必要的数据。我发现使用Breeze我们可以创建业务逻辑，当使用延迟加载策略时，可以将数据传输/传输减少1/10甚至更多。使用these
等查询Hooray breeze !!!
但是商业逻辑安全性呢， 例如，我们可以拥有一个存储库，我们可以在其中隐藏，隐藏和模糊我们的业务逻辑;然后使用MVC Web API控制器来调用这些存储库C＃类。所以Breeze JavaScript与WebAPi控制器进行通信，WebApi控制器与C＃存储库进行通信。控制器将始终保持非常简单和易于阅读，但存储库最终可能会使用该应用程序为公司提供大量业务逻辑。因此，如果黑客使用谷歌Chrome开发人员的控制台来检查JavaScript代码，那么他/她将看到的就像GetCustomers（），GetProductsForThisId（54）。那里没有太多可以看到（或被盗）的信息。因为90％的业务逻辑将存在于服务器上的C＃存储库中。
breeze.js如何处理？
如果我们开始将查询和业务逻辑“从控制器的C＃移动到微风JavaScript”，我们必须考虑到我们的系统是基于成员资格的。我认为我们在JavaScript中向客户端公开的查询越多，我们的软件就越容易受到攻击，我们就越会告诉黑客如何破解我们的网站并可能窃取信息。
答案 0 :(得分：44)
安全是一个至关重要的问题。仔细考虑客户端上暴露的数据和逻辑是明智的。我们如何将这些情绪细化为适合SO答案的具体问题？
Breeze的任何内容都不应该让您将业务逻辑暴露给JavaScript客户端。您可以（并且应该）在存储库和/或控制器方法中安全地锁定此类逻辑。
但我很难理解客户端 自我查询 是多少需要保护的业务逻辑。查询名称以“A”开头的客户的危险在哪里？
您可能正确地担心对净资产＆gt;的客户进行查询$ 100,000。但是错误不在查询中。无论是通过Breeze where 子句附加到查询还是调用名为的服务，错误都是将此类客户信息以任何方式暴露给未经授权的用户; GetCustomers的（）
阻止未经授权访问客户的地方在服务器上，您可以在Breeze控制器操作方法中轻松地执行此操作，并在 GetCustomer（）中返回 IQueryable 方法。在任何一种情况下，您都要承担必要的安全约束，并在您公开的方法中施加必要的安全约束。
你写控制器。你写了存储库。您可以访问用户的权限。您可以完全掌控并具有无可挑剔的能力，可以根据自己的喜好进行曝光。
FWIW，您的Breeze EntityManager 可以调用不返回IQueryable<Customer>的服务方法。它可以调用Web Api控制器方法，例如 IEnumerable<Customer> GetCustomers() 或 Product GetProductForId(int id) 。在我看来，如果不获得任何安全性，您将失去Breeze查询工具的灵活性。但那只是我的个人意见。 Breeze将支持您的选择，无论它是什么。
我很乐意尝试回答更具体的“如何”问题。
答案 1 :(得分：2)
我想补充一点，如果从服务器返回401代码，只需弹出登录屏幕并重做用户登录后所需的工作，就可以使用webapi中的属性限制未经授权的用户查询< / p>
因此用户可能会尝试获取有关订单的数据，但除非获得授权，否则他将无法获取该订单
答案 2 :(得分：1)
你可以使用breeze.js来处理很多东西 首先检查我关于安全性的答案
How to handle authorization with Breeze JS?
虽然breeze.js可以像客户端上的普通ORM一样使用（有时可能非常有用），但您应该将您的业务逻辑保留在web api控制器中，并使用OData查询仅公开必要的东西。 如果您需要任何数据操作逻辑，那么您应该使用特定的方法在服务器上执行此操作。
客户端上只应存在UI逻辑，如果您直接从客户端开始执行多个查询，也会考虑性能影响。扩展实体图以加载更多结果或使用返回对象的更专业方法。 Breeze会反思结果并愉快地消耗实体而没有任何影响。