Breeze/OData调用FetchEntityByKey时使用了过滤器（未使用EntitySetController.GetEntityByKey）。

Question

使用Breeze与OData并调用entityManager.FetchEntityByKey()时，将发送以下请求：

/odata/Customers?$filter=Id eq 2

我本来会期待

/odata/Customers(2)

您是否可以使用后者来制作Breeze？

更新2013年12月10日：

是的！我已经想出了以下方法（在我看来，FetchEntityByKey应该这样做）：

entityManager.executeQuery('Cusotmer(2)') ...

然后发出以下请求：

/odata/Customers(2)

但是！现在似乎Breeze（v1.9.6）无法正确处理结果。返回的结果数组为空。实际上，它应该只返回一个项（实体），而不是一个数组。

用户反馈链接

我已经创建了一个用户反馈

- iwhp

Answer 1

你真的关心Breeze生成的URL是/odata/Customers(2)还是/odata/Customers?$filter=Id eq 2吗？为什么？

它们都是合法的OData。OData服务器将愉快地为您提供任何查询的正确答案。

Breeze确实更喜欢后者，原因如下： Customers(2)语法返回一个对象或空值（而不是404未找到）。 Customers?$filter=Id eq 2过滤语法总是返回一个数组。该数组有一个或零个项目，但是你将获得一个数组。

我们在客户端上的简化之一是查询始终返回一个data.results数组。我们只有一个查询结果API，即data.results始终是一个数组，无论您如何查询。您无需测试data.results是否为空。也不必记住“我的查询返回一个对象还是一个数组？”

这是我们指导客户端一致性原则。我们不太可能偏离这个原则。

正如发生的那样，您可以拦截URL生成并在必要时更改它。这是给你的练习。当然（正如你发现的），你需要做一些工作才能将结果转回数组。忽略这一点是我怀疑你试图欺骗Breeze进入其他语法Customers(2)导致混乱的空数组结果的原因。

除非我们得到一些严重的反弹和令人信服的理由，否则我们不太可能改变默认行为。

- Ward

---

感谢您的反馈。原因是服务器上有两个不同的函数，一个处理/odata/Customers(2)，另一个处理/odata/Customers?...。有许多原因为什么客户端希望使用“适当”的函数（OData标准会假定这一点，实现细节可能不同，安全问题、跟踪问题等）。在我看来，我认为最重要的一点是OData标准定义。Breeze应该调用OData定义提出的函数。 - iwhp

Breeze 总是返回一个数组，这个原则很好，我非常喜欢它。如果你想改变 FetchEntityByKey，使其调用 Customers(2)，你可以将结果封装成一个数组，这样你就可以坚持这个原则了;-) - iwhp