これには「ルール」がありますか？私が疑問に思っているのは、機能を操作に組み合わせる方法を示すベストプラクティスがあることです。たとえば、SetRecord-operation: id がある種のレコードに指定されている場合、オペレーションはレコードを更新します。それ以外の場合、オペレーションはレコードを作成します。この場合、戻りメッセージは挿入または更新が行われたかどうかを示しますが、これは悪い設計でしょうか (もしそうなら、なぜですか)?
もう 1 つの例は、レコードの包含階層があり、すべてのレベルの階層を作成したい場合もあれば、2 つのレベルを作成したい場合もあれば、1 つのレベルだけを作成したい場合もあります。場合によっては、車または単一の座席のみが作成されます。場合によっては、4 席 (それぞれに 2 つのアーム レストがある) の車両が作成されることもあります。これが wsdl-operations および type にどのようにマップされるか。意見があれば、理由を知りたいですか？私はここで少し道に迷ったと言わざるを得ません。
ありがとう、BR - Matti
それを行っても問題はありませんが、優れたプログラミング パターンのいくつかの原則に違反しています。
メソッドとクラスは、1 つのことだけを行うべきであり、複数のことを行うべきではありません。単一責任の原則は、まさに次のように述べています。
単一責任の原則 (SRP) では、クラスには変更する理由が 1 つだけある必要があると述べています。別の言い方をすれば、クラスのメソッドは同じ理由で変更する必要があり、異なる速度で変化するさまざまな力の影響を受けるべきではありません。
また、次のような他の原則にも違反する可能性があります。
次のような多くのコードの匂いにつながる可能性があることは言うまでもありません。
Long メソッド
の条件付きの複雑さ
この良いテキストを確認してください。
私はいくつかの調査を行いましたが、上記の答えは wsdl インターフェイス設計の非常に狭い視野を示していると思います。私の質問の例の Insert と Update を Set に組み合わせて、実行された操作がデータから推測されるようにするのはばかげています (ID または同様のものが要求メッセージに入力されているかどうかを確認します)。そのような場合、インターフェースは実際に何が起こるかを述べていないので、それは悪いことです. 2 つの別々の操作を持つことは、はるかに明確であり、それ以上リソースを消費しません。
ただし、操作を組み合わせることは、物事を行うための正しい方法です。私の階層データの例を考えてみましょう。4 席の車で、すべてに両方のアームレストがある場合、13 のリクエストが必要です。すべての国境検問所は費用がかかると予想されます。したがって、これは単一の操作に組み合わせることができます。
例を読んでください：
と
http://msdn.microsoft.com/en-us/library/ms954638.aspx
そして、上記の回答は明らかに単純化しすぎており、すべてのプログラミング原則を Web サービス インターフェイスの設計に自動的に適用することはできないことがわかります。
上記の SO-answer の良い例は、1 番目のオーダー ヘッダーを作成することであり、個別のリクエストでアイテムを注文することは、遅くて信頼性が低いなどの理由で悪いことです。それらはに組み合わせることができます
PlaceOrder(invoiceHeader, List<InvoiceLines>)
したがって、答えは次のとおりです。それは、何を組み合わせるかによって異なります。あまりにも低レベルの CRUD のようなものはうまくいきませんが、組み合わせる必要のないものを組み合わせることもすべきではありません。さらに、単純に複数/単一にするのではなく、何が行われるかをすぐに伝える明確なメッセージ構造を備えた明確なインターフェイスを定義することがここでの鍵です。
-マティ