适用于纯前端/UI 开发人员的 BreezeJs答案

【问题标题】：BreezeJs for pure frontend/UI developers适用于纯前端/UI 开发人员的 BreezeJs
【发布时间】：2014-01-23 09:51:39
【问题描述】：

对于一个纯粹的 UI 开发人员团队，不知道如何实现 oData 服务（一个没有任何 dotNet 知识/经验的 UI 团队）：

我们如何确保后端 oData 服务层能够与我们的 BreezeJs 前端/UI 代码正常工作？

对于 BreezeJs javascript 编码员来说，拥有后端 odata 实现知识重要吗？

有没有办法验证/证明给定的 URL/odata 服务点可以与 BreezeJs 一起正常工作？

我问这些问题的原因是：通过我们的后端 oData 服务实现，我们发现 oData url/services 接受 POST 方法进行更新和删除操作。在我看来，这与 REST 约定不符。

我们的 oData url/services 还接受一些特殊的标头，例如 X-HTTP-method 的值，例如“PUT”、“MERGE”等。

这就是为什么我要问：breasureJS 编码人员应该具备 odata 后端实现知识吗？

我们的编辑/保存操作没有通过 BreezeJs 与后端同步。但是，我们的读取操作运行良好。

请注意：我们使用 AngularJS 和 BreezeJS。我们想使用 AngularJS 和 BreezeJS entityManager 之间的数据绑定来进行所有同步。

【问题讨论】：

【解决方案1】：

另一个答案是不知情且不正确的。 Breeze 遵循您告诉它的约定。

Breeze 具有高度可配置性，可以使用您选择的任何后端技术。如果您在命名服务端点时选择遵循 RESTful 约定，那么在客户端上有一个快速帮助服务来构建您希望的这些端点。我一直都这样做。如果你想对你的 api 服务执行一个检查表，看看它们是否遵循休息约定，让后端团队来做。

您必须知道您的服务接受哪些参数以及接受它们的方式。

作为记录，PUT 和 DELETE 目前不在 Html 5 规范中，因为它们不一致。使用 POST 进行添加和删除更安全且兼容浏览器。

【讨论】：

【解决方案2】：

当两个团队，一个纯正面，一个纯背面，在同一个项目上工作时，这是一个常见的问题。

如果您使用 REST，请遵守约定，以便 Fronters/Backers 知道他们说的是一种通用语言。

如果您使用 SOAP，您可以定义一个 XML 文件作为两个世界之间的契约。

BreezeJS 不遵循 REST 约定，也不遵守合同，并且遵循文档可能还不够。所以答案是：是的，您必须了解后端实现，并添加强大的集成测试以确保通信顺利进行。

【讨论】：