2

現在、モバイル アプリケーションで使用される OData 準拠のエンティティ データ モデルを設計しています。チームは2つに分かれています。OData サービスを提供するバックエンド開発者と、これらのサービスを利用するフロントエンド開発者です。

フロントエンド開発者とバックエンド開発者の間の意見の相違点の 1 つは、メイン エンティティの設計に関するものです。フロントエンドの観点からは、次のようになります。

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

Order オブジェクトは、次のような URL でクエリされます。

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 Services 設計の一般的な方法ですか?

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 に答える