SOA WCF Webサービスを設計する際のベストプラクティスは何ですか？

Question

次のような運用契約が与えられた

[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にカスタムメッセージ処理を追加しないようにします。私はおそらくすべてのタグが小文字で始まると信じている最も一般的なSOA XML規約に従いたいと思います-私は正しいですか？そして、できるだけバージョンに寛容になりたい。

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

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

Answer 1

XMLは通常、キャメルケースになる傾向があります。 WSDLおよびSOAPスキーマは、要素と属性の両方にcamelCasingを使用します。たとえば、構文をチェックアウトしますおよびスキーマ。

なぜWS*が異なって定義されたのか、私にはわかりませんが、要素にはPascalCasingを、属性にはcamelCasingを使用します。こちら。

類似、ほとんどのSOA仕様（すべて）が要素と属性にPascalCasingを使用しています。こちら。 XMLスキーマは、XMLに対して定義する型の規則にとらわれません。

Thomas Erl は、 WCF <！> quot; Service-Oriented Architecture <！> quot;を含む。 13 と 15 の章では、典型的なトランザクションのさまざまな部分のXMLの例をいくつか提供しています。 PascalCasingを使用してXMLスキーマで型とオブジェクトメンバを定義します。PascalCasingは、クラスとプロパティの命名に関するC＃の通常のパターンとうまく一致します。したがって、OperationContractデフォルトはすでに標準にほぼ一致しています。

実際のメッセージの命名については、一部の規則ではcamelCasingが使用され、他の規則ではPascalCasingが使用されるため、私の好みは主要言語のニーズ（DataContractの場合はPascalCasing）に一致することです。また、MessageContractデフォルトは、要求および応答メッセージの記述方法のいくつかの例と一致します。ここのいくつかの例。

したがって、唯一の未解決の質問は、XSD、<=>、および/または<=>の使用に関してどれだけ標準化するかという基本的な質問です。

DataContractを定義するのは、複雑な型（<=>の用語）がある場合にのみ意味があり、Terryが指摘したYAGNI（You Ai n't Gonna Need It）が正しい選択だと思う傾向がありますが、< em> Erl は、はるかにプロセス集約型のバージョンを示唆しているようです。そのため、デフォルトの選択肢（質問の主要部分）として使用する最善のアプローチがまだわかりません。

Answer 2

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

私はビジネス統合チームで働いており、他の会社とかなり定期的に統合しています（AT <！> amp; T、Cox、Exxon ...）。 。

Answer 3

正直なところシナリオに依存すると思います。単純な型を交換するだけの場合[つまり、文字列]、OperationContractは確かに受け入れられます。

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

Answer 4

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

私は、未来を見つめすぎてやり過ぎないことを言います。 WCFはすでにSOAに適しています。一般に、デフォルトにこだわると言います。具体的な操作が必要になるまで、結合に注意してください。