通常の get および get メソッドだけでなく、多数の関数を含む複雑なデータ型があります。クライアントもこのデータ型を使用できるように WCF を使用できれば、私の生活はかなり楽になります。
私はしますか
すべての操作を無視し、
[DataMemeber]
必要な場所にのみ配置します。問題のクラスを、クライアントとサーバーの両方がアクセスできる共有ライブラリ アセンブリに配置します。
ありがとう、ロベルト
PS。質問の言葉遣いが適切でないことは承知しています。
通常の get および get メソッドだけでなく、多数の関数を含む複雑なデータ型があります。クライアントもこのデータ型を使用できるように WCF を使用できれば、私の生活はかなり楽になります。
私はしますか
すべての操作を無視し、[DataMemeber]
必要な場所にのみ配置します。
問題のクラスを、クライアントとサーバーの両方がアクセスできる共有ライブラリ アセンブリに配置します。
ありがとう、ロベルト
PS。質問の言葉遣いが適切でないことは承知しています。
WCF の境界を越えて転送されるのは、シリアル化されたもの、つまりクラスの状態に相当するものだけです。メソッドはそうではありません。したがって、それらを両側で利用できるようにする必要がある場合は、提案したように共有ライブラリが必要になります。
サービス参照を追加するとき、データ型を再利用するオプションがあります。その場合、WCF はメソッドを備えた共有クラスに逆シリアル化します。しかし、実際に境界を越えて転送されたのはフィールド値だけです。
わかりました、それは上記のすべての答えの組み合わせであることがわかりました.
コードは次のようになります。
[DataContract]
[KnownType(typeof(WHS2SmugmugShared.Photo))]
[KnownType(typeof(WHS2SmugmugShared.PhotoInfo))]
public class Photo
{
//code here
}
上記の場合、Photo クラスで PhotoInfo を使用します。PhotoInfo には、クラス ファイルで関連付けられている KnownType 属性がありません。そして、それは必須ではないようです。
これにより、複雑な型をシリアル化しながら、操作を維持できます。
データ コントラクトのベスト プラクティスは、それをコントラクトにすることです。データのみで動作はありません。2 番目のベスト プラクティスは、クラスを [DataMember] で装飾し、それをサーバー上に保持することです。クライアントにプロキシ コピーを使用させます。
そのようなすべての型をシリアル化可能な属性で装飾します。そのため、WCF サービスに参加する複雑なクラスごとに [DataContract] 属性を配置する必要はありません。
これらの型を含む dll を WCF クライアントに追加し、デシリアライゼーションに必要なクラスを再生成する代わりに、プロキシがそれらのクラスを再利用できるようにします。また、タイプがproxyに追加されている場合は、それを削除してdllから使用してください。このようにして、複雑な型をサービス間で簡単に共有できました。 ただし、タイプを別のdllとして共有できる場合にのみ適用できます。
簡単な答え: はい。WCF は、チャンピオンのように複雑な型を処理します。複合型を渡すときは、渡されるデータだけに集中する必要があります。クライアントが DLL を共有していない場合、クライアントは複合型のデータ メンバーのコピーのみを取得するため、渡されるデータ (追加の操作ではなく) だけに注目することがさらに重要になります。
あなたはJavaのバックグラウンドを持っていると思いますか?WCF では、フィールドを DataMember 属性でマークするか、(できれば) get/set メソッドをプロパティに変更する必要があります。
たとえば、次の代わりに:
[DataContract]
public class Foo
{
[DataMember]
private string bar;
public string GetBar()
{
return bar;
}
public void SetBar(string b)
{
bar = b;
}
}
以下を使用できます。
[DataContract]
public class Foo
{
[DataMember]
public string Bar { get; set; }
}