複数のDTOと単一のDTOとプリミティブ

Question

Webサービスメソッドのパラメーターを指定するときの最善の方法とその利点は何ですか。例を通してそれを説明するのが最善です。

Xamarinモバイルアプリで使用される（SOAP）WebServiceには、WebMethod SubmitForm(int, TransactionData, List<Answer>)があります。ここで、

intはプロジェクトのIDであり、接続するデータベースを指定します。

TransactionDataは、ユーザーとフォームに関するデータを含むDTOであり、

Answerは、単一の質問のIDと回答を含むDTOです。

TransactionDataとAnswersには別々のテーブルがあるため、これらは互いにかなり無関係ですが、これら3つのオブジェクトを含む新しいDTO、SubmitRequestを作成することを検討しています。可読性を除いて、これらのオプションの長所と短所は何ですか？また、SubmitRequestからインスタンス化して抽出するためのわずかなオーバーヘッドはありますか？

考慮すべきもう1つの状況は、intなどの単一のプリミティブ型を受け入れるWebMethodです。プロパティを1つだけ含むintをそのまま受け入れるか、DTOでラップするほうがよいでしょうか。率直に言って、私は後者のファンではありません。なぜなら、あなたは文字列やintなどのDTOになってしまうからです。

したがって、質問は、システムにとって最も有利なものは何ですか？違いさえありますか？それとも、それは単に個人的な好みの問題ですか？

Jorge Armando Palm · Accepted Answer

ここで解凍することがいくつかあります。

メソッドに複数のパラメーターがある

パラメータのorderに関する知識が必要になるため、メソッドの呼び出し元への依存関係が作成されます。パラメーターが何であるかを意味的に表す単一のパラメーターを持つことは、物事をもう少し分離するのに役立ちます。判断に基づいて、「多すぎる」前に許容できるパラメータの数を決定します。

1つのモデルで2つのモデルをラップする

それはうまくいかなかったり、コード全体のセマンティクスを改善する可能性があります。メソッドに複数のパラメーターがある場合、それらが何らかの関係（秘密の関係）を持っている可能性があります。それらはそれを何と呼ぶかわからないので、あなた次第です。それらは互いに属しているか、1つに属しているかもう一方、どちらもより高い抽象レベルに属しています。

ここで追加することは、モデル/ DTOがDBスキーマを反映する必要がないということです。したがって、両方のモデルをDTOに配置しているからといって、相互に外部キーが必要になるということではありません。 DTOの1つをもう一方の内部に置く場合にのみ必要です。

プリミティブメソッドをパラメーターとして使用する

意味論は面倒な価値がありますか？ある場合もあるし、ない場合もあります。もう少し良い名前を付けることに価値がありますか？それは多分すべてのパラメータの事件の悪名高い子製品の特性であるべきですか？多分。しかし、それが1つのパラメーターであり、それがプリミティブである場合...私は何でもします。

お役に立てれば。あなたの考えを聞かせてください。

Berin Loritsch · Answer

正直に言うと、3は、個人的な好みに応じて自由にできるAPI設計に大きな余裕があります。とはいえ、その選択は設計決定のトレードオフによって通知されるべきです。 SOAPは、関数に個別の引数があるかのように動作できるため、ある意味で少し誤解を招きますが、シリアル化された要求を見ると、すべてが非常に冗長なXML構造にカプセル化されています。基本的に、それらすべてを支配する「1つのDTO」。フレームワークはそれをあなたから隠します。

SOAPの設計上の制約により、質問について考えることができます。あなたの説明に基づいて、私の個人的な好みは、SOAP APIを通常のオブジェクト指向プログラミング（OOP）のように扱うことです。実装しているメソッドがリモートで呼び出されるように設計されているため、本質的に、別々のオブジェクトを保持するのと同じ思考プロセスを大きなオブジェクトにカプセル化するのとでは変わりません。

それでも、SOAPにはいくつかの注意点があります。

SOAPを使用して、blob（バイナリラージオブジェクト）をバイトの配列として送信しないでください。その配列を一度にメモリに読み込む必要があります。サイズによっては、 APIのメモリが不足します。
配列と非常に大きなオブジェクトには注意してください。制限のない入力は、添付ファイルをバイトの配列として送信するのと同じように、メモリの問題を引き起こす可能性があります。ほとんどのフレームワークには、遅延読み込み機能や部分的なドキュメント読み込み機能はありません。
可能な場合は、プリデシリアライゼーションバリデーターを使用して、DOS攻撃からAPIを保護します。基本的に、リクエストのパッケージ全体が特定のバイト数を超える場合、手に負えずに拒否されます。多くのWebサーバーでは、最大リクエストサイズを指定できます。悪意のある人々は、処理するには大きすぎるパッケージを送信することにより、悪いエラー処理を悪用する可能性があります。

ストーリーはJSONによって多少変わります。 JSONで親リクエストオブジェクトが必要な理由は、SOAPのように引数の周りに標準化されたカプセル化がないためです。正直なところ、上記でSOAPと共有した同じ警告は、JSONにも影響します。ただし、SOAPの場合のように、これらの警告に違反するJSON APIを実際に目にすることはありません。