2

私はサービス契約を結んでいます：

[DataContract]
public class Something
{
    [DataMember]
    public MyEnum SomeEnumMember {get;set;}
}

私たちの開発者の何人かはこの種のことをしています：

public Something()
{
    SomeEnumMember = MyEnum.SecondEnumValue;
}

「サービス参照の追加...」を使用し、Visual Studioによって生成されたプロキシクラスを使用している場合、そのコードは機能しないため、コンストラクターロジックはサービスコントラクトに属していないと思います。

内部的には、ここに示すようにCastleDynamicProxyを使用しています。ただし、何らかの理由でDynamicProxyを使用できない場合に備えて、開発者はサービスコントラクトクラスのコンストラクターロジックを避けたいと思います。

つまり、コンストラクターロジックはこれらのクラスに含まれるのでしょうか。それとも、ベストプラクティスとして、コンストラクターロジックをより多くのDTOと見なし、動作なしで実装する必要があるのでしょうか。

4

2 に答える 2

1

私はあなたに同意します、私はコンストラクターロジックがそこに属しているとは思いません、そして私は実際にコンストラクターロジックを含むwcfで作業したことはありません。

于 2012-05-11T19:55:32.713 に答える
1

そもそもサービスを介して転送するオブジェクトを作成する場合にのみ、違いが生じる可能性があります。SomeEnumMember便宜上、送信をインスタンス化するときにデフォルト値を変更したい場合は、次のようにするのが理にかなっています。

var mySomething = new Something();
mySomething.SomeEnumMember = MyEnum.SecondEnumValue; //this line may be omitted if it's set automatically by the constructor
SendData(mySomething);

受信側では、値（私が思うに、そしてあなたのテストから）はとにかく送信者によって明示的に設定されるので、違いはありません。さらに、オブジェクトをインスタンス化/逆シリアル化するレシーバーによる余分な/無駄な作業になりますが、これはごくわずかなオーバーヘッドである可能性があります。

一般に、データ転送オブジェクトにはロジックが含まれていてはなりません。おそらく、アプリケーションアーキテクチャによっては、情報を転送するだけでなく、このオブジェクトをさまざまな場所で使用している場合は、意味があるかもしれません。私はそのアーキテクチャに疑問を投げかけますが、クライアント/サーバー通信に関係するオブジェクトを他のアプリケーションアーキテクチャから抽象化しておくのが好きです。そうすれば、他のアプリケーションに深刻な影響を与えることなく、自由に変更（特殊なシリアル化、アーキテクチャの変更など）を行うことができます。

于 2012-05-11T20:06:28.767 に答える