11

次のような運用契約がある場合：

[OperationContract]
void Operation(string param1, string param2, int param3);

これは次のように再設計できます。

[MessageContract]
public class OperationRequest
{
    [MessageBodyMember]
    public string Param1 { get; set; }

    [MessageBodyMember]
    public string Param2 { get; set; }

    [MessageBodyMember]
    public int Param3 { get; set; }
}

[MessageContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

MessageContractについて私が気に入っていることの1つは、SOAPメッセージの形式をもう少し明示的に制御できることです。

同様に、ほぼ同じコードを記述できますが、DataContractを使用します。

[DataContract]
public class OperationRequest
{
    [DataMember]
    public string Param1 { get; set; }

    [DataMember]
    public string Param2 { get; set; }

    [DataMember]
    public int Param3 { get; set; }
}

[DataContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

DataContractについて私が気に入っていることの1つは、IsRequired、Order、およびNameを定義できることです。

今日、私は唯一の消費者がWCFクライアントになることを期待しています。ただし、最初に契約を設計し、SOAの慣行を可能な限り遵守したいと思います。WCFにSOAP、WSDL、およびXSDを指示させるのではなく、XMLでWCFレイヤーを定義する必要がありますが、カスタムメッセージ処理をWCFに追加しないように、WCFを使用してこれを生成します。おそらくすべてのタグが小文字で始まると思われる最も一般的なSOAXML規則に従いたいのですが、正しいですか？そして、私は可能な限りバージョントレラントになりたいと思っています。

常にこのような要求メッセージと応答メッセージを作成するのが賢明ですか？3つのフォーマットのどれがベストSOAプラクティスを促進しますか？さらに一歩進んで、DataContractとMessageContractの両方を定義し、MessageContractにDataContractのみが含まれるようにする必要がありますか？または、本当に新しいタイプを公開している場合（つまり、メッセージタイプをコンテナーとして作成しない場合）にのみDataContractsを使用する必要がありますか？

たくさんの質問がありますが、その核心をつかもうとしています。質問を分離することで、探している答えを得るのに十分なコンテキストが得られるかどうかはわかりません。

4

4 に答える 4

15

操作コントラクトに複数のパラメーターを持たないことが常にベスト プラクティスであり、必要なパラメーターをすべてラップする型を常に持つことは、長期的には役立ちます。新しいオプション パラメーターを追加しても、既存のクライアントが壊れることはありません。

私はビジネス統合チームで働いており、他の企業 (AT&T、Cox、Exxon など) とかなり定期的に統合していますが、1 つ以上のパラメーターを使用する Web サービス呼び出しを見たことがありません。

于 2009-06-26T05:47:30.313 に答える
6

XML通常はキャメルケースになる傾向があります。WSDLおよびXMLスキーマは、要素と属性の両方にキャメルケースを使用します。たとえば、構文とスキーマを確認してください。

定義が異なる理由SOAPはわかりませんが、要素には PascalCasing を使用し、属性には camelCasing を使用しています。ここを確認してください。

同様に、仕様のほとんどWS*(おそらくすべて) は、要素と属性に PascalCasing を使用します。こちらを参照してください。XML スキーマは、XML に対して定義する型の規則にとらわれません。

Thomas ErlSOAは、「サービス指向アーキテクチャ」を含む多くの重要な本を書いています。第13章と第15章では、典型的なトランザクションのさまざまな部分の XML の例を多数提供しています。PascalCasing を使用して、XML スキーマで型とオブジェクト メンバーを定義します。これは、クラスとプロパティの命名に関する C# の通常のパターンとうまく一致します。したがってWCF、デフォルトはすでに標準にほぼ一致しています。

実際のメッセージの命名に関しては、キャメル ケーシングを使用する規則もあれば、パスカル ケーシングを使用する規則もありますWCF。また、WCFデフォルトは、リクエストおよびレスポンス メッセージの書き方の例と一致します。いくつかの例はこちら.

OperationContractしたがって、唯一の未解決の問題は、 、DataContract、および/またはの使用をどの程度標準化するかという基本的な問題ですMessageContract。

複雑な型を持っている場合にのみ DataContract を定義することXSDは理にかなっており、Terry が指摘したように YAGNI (You Ain't Gonna Need It) が正しい選択であると私は考える傾向がありますが、Erlはそれ以上のことを示唆しているようです。集中的なバージョンを処理するため、デフォルトの選択として使用する最善のアプローチがまだわかりません(質問の主要部分)。

于 2009-02-01T23:50:51.067 に答える
0

ここでYAGNIが思い浮かびます。

将来を見据えて空想しすぎないようにしましょう。WCFはすでにSOAに対応しています。一般的に、デフォルトに固執し、何か手の込んだことをする必要があるまで、結合に注意してください。

于 2009-01-26T03:34:56.660 に答える
0

正直シナリオによると思います。単純な型 (つまり文字列) を交換するだけなら、OperationContract は確かに受け入れられます。

メッセージ形式を変更する場合は MessageContract を使用し、アドレスなどの複合型を表現する場合は DataContract を利用する必要があります。

于 2009-01-26T01:36:08.587 に答える