OData 实体设计：用于查询的附加字段答案

【问题标题】：OData Entity Design: Additional field for queryOData 实体设计：用于查询的附加字段
【发布时间】：2015-07-31 03:23:59
【问题描述】：

我们目前正在设计将由移动应用程序使用的符合 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也计划用在更新场景中，前端更新Order实体时预计会通过Request Code。这样，后端通过查看请求代码就可以知道要更新哪些字段。

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

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

【问题讨论】：

标签： mobile odata ado.net-entity-data-model

【解决方案1】：

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

OData 查询接口应该足以描述大多数情况。不够的时候可以创建service operations来描述额外的业务语义。

例如，这个：

/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 已经支持updating individual properties。

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

【讨论】：