2

我们目前正在设计将由移动应用程序使用的符合 OData 的实体数据模型。团队分为两个；提供 OData 服务的后端开发人员和使用这些服务的前端开发人员。

前端和后端开发人员之间的分歧之一是关于我们主要实体的设计。从前端的角度来看，它应该是这样的：

Order:
Order ID
Order Type
Assigned To
Customer ID
Price
Currency
etc...

将使用以下 URL 查询 Order 对象：

http://SERVICE_ROOT_URL/Orders?$filter=Order_Type eq 'Inquiry' or Order_Type eq 'Quotation'
http://SERVICE_ROOT_URL/Orders?$filter=Order_Type eq 'Inquiry' and Assigned_To eq 'James7'

后端开发人员愿意为 Order 实体添加一个新字段，并使用该字段来了解用户正在查询的内容。让我们将这个新字段命名为Request Code。使用请求代码字段，查询将如下所示：

http://SERVICE_ROOT_URL/Orders?$filter=Request_Code eq '0022' // The orders requiring approval and the current user can approve them
http://SERVICE_ROOT_URL/Orders?$filter=Request_Code eq '0027' // The orders with the open status

基本上，Request Code它不是实体的实际部分，而是人造的。它只是增加了一些智能，以便后端的查询变得更容易。这样，后端将仅支持具有此请求代码的那些查询。也计划在更新场景中使用，在更新实体时Request Code，前端预计会通过。这样，后端将通过查看请求代码来知道要更新哪些字段。Request CodeOrder

我在前端，我认为不Request Code应该包含在模型中。它使设计加密并消除了 OData 服务的简单性。除了让后端的事情变得更容易之外，我也没有看到任何附加价值。

这是 OData 服务设计中的常见做法吗？

4

1 回答 1

4

对我来说，这个额外的属性是不合适的。它在 OData 之上增加了一层额外的语义；这需要额外的理解和额外的编码来处理。它只会增加意外的复杂性，它会将后端实现细节泄漏到其公共 API。

OData 查询接口应该足以描述大多数情况。当这还不够时，您可以创建服务操作来描述额外的业务语义。

因此，例如，这个：

/Orders?$filter=Request_Code eq '0022' // The orders requiring approval and the current user can approve them
/Orders?$filter=Request_Code eq '0027' // The orders with the open status

可以变成这样：

/GetOrdersRequiringApprovalFromUser
/GetOpenOrders

此外，对于更新逻辑，OData 已经支持更新单个属性。

因此，总而言之，不要在 OData 之上发明另一个协议。使用它提供的东西。

于 2013-02-13T18:05:29.637 回答