問題タブ [datacontract]

WCF データ コントラクトを定義する場合、コレクション/リストにはどの型を使用する必要がありますか?

• ICollection<T>、IList<T>、T[]、または...?
• インターフェイス型または具体的な型を使用する必要がありますか?
• どのようなトレードオフを考慮する必要がありますか?

この形のデータ コントラクトを持つことはできますか??

ここでは、MonthlyStatistic クラスも DataContract である必要があると想定しています。Webサービスでこれを行うことはできますか?

ツリー構造を保存（シリアル化）して後で開く（逆シリアル化）ための最良の方法を見つけようとしています。私の構造は、さまざまなプロパティを持つさまざまなオブジェクトタイプで構成されていますが、それぞれが基本抽象「Node」クラスを継承しています。

各ノードには一意のID（GUID）があり、ノードの親を設定するAddSuperNode（Node nd）メソッドがあります。これにより、親ノードがどのサブノードを持っているかを知ることができる他のメソッドが呼び出されます。ただし、一部のノードは、ノードにセカンダリ親を追加するAddAuxSuperNode（）メソッドも利用します。

バイナリシリアル化を使用していましたが、今はもう少し制御しやすく、シリアル化されたデータにアクセスしやすいものを使用したいと思います。また、逆シリアル化するときにタイプ情報を保持し、プライベート値をシリアル化できるようにしたいです。したがって、 DataContractSerializerは最善の方法のように思われました。

ノードに複数の親があるため、ルートノードを直接シリアル化することはできません。重複するオブジェクトを作成したくありません。したがって、ツリーをフラットリストに分解してから、シリアル化する必要があるように思われます。次に、そのリストをシリアル化した後、ツリーを再構築します。これは正しいですか？

前に述べたように、各ノードには一意のGUID識別子がありますが、現在、ノードは親/子を直接参照しており、IDを保存していません。AddSuperNode （）メソッドとAddAuxSuperNode（）メソッドを更新して、直接参照に加えて、シリアル化する親IDのリストも更新できます。ただし、オブジェクトがシリアル化されているときにのみ、このリストを更新/作成したいと思います。そのため、シリアル化の直前に呼び出されるノードにUpdateSuperNodeIDRefs（）メソッドを作成することを考えていました。

以下は、この構造のシリアル化と逆シリアル化のために私が計画していることです。誰かがこれを行うためのより良い/よりクリーンな/より効率的な方法を提案できますか？

シリアル化

1）ツリー構造のルートノードを提供します

2）ツリー構造をフラットな辞書（Guid id、Node nd）に分解します。ここで、idはndのGUIDです。

3）UpdateSuperNodeIDRefs（ ）を呼び出します; 各ノードがその親のために保存したIDを更新します。

4）DataContractSerializerを使用してノードのディクショナリをシリアル化します

デシリアライズ

1）ノードのディクショナリを逆シリアル化します

2）ディクショナリ内の各ノードを繰り返し処理し、それぞれを親に再接続します。保存されている親IDについては、一致するIDを持つ辞書でそれぞれのノードを見つけ、AddSuperNode （）またはAddAuxSuperNode（）を呼び出して、ノードをその親に再接続します。

3）ディクショナリ内の任意のノードから、構造のルートを見つけます

4）ルートノードを返す

シリアライゼーションのための DataContracts の設計の 1 つの点で、私はかなり混乱しています。

オブジェクト (Customer など) があり、コレクション プロパティ (Addresses という名前の AddressCollection など) を公開するとします。フレームワークの設計ガイドラインでは、プロパティのパブリック ミューテーターを公開しないように規定されています。つまり、コレクション プロパティには get と no set が必要であり、代わりに public set メソッド (public void SetAddresses(IEnumerable< Address> addresses)) を使用する必要があります。

しかし、そのオブジェクトをシリアル化する必要があり、部分信頼環境になると予想される場合、適切に逆シリアル化できるように、パブリック セッターをプロパティに追加する必要がありますか?

さらに、シリアル化時にコレクションに何も含まれていない場合、デフォルトのコンストラクターは DataContractSerializer によって呼び出されないため、コレクションがまったく設定されておらず、null のままになっていると確信しています。OnSerializing 属性を使用してコレクションを初期化することもできますが、部分信頼シナリオではそのメソッドもパブリックにする必要がありますね。そして、それはさらに醜いです。

ここで適切なガイダンスを知っている人はいますか?

どうもありがとう。

私は WCF の初心者ホワイトベルトです。

名前空間があります: http://schemas.datacontract.org/2004/07/System/ArgumentException。

その文字列を取得して CLR 型に変換し、最終的に typeof(ArgumentException) になるようにしようとしています。

これは可能ですか？:)

ありがとう、MichaelD

いくつかのオブジェクトを公開するクラスライブラリを使用しています。これらのオブジェクトには、クライアントが必要とするデータを保持するいくつかのプロパティがあります。オブジェクトをクライアントに返すWCFサービスを作成したいのですが、DataContract属性とDataMember属性を追加するためにクラスライブラリを更新できません。これらのオブジェクトを公開する最も簡単な方法は何ですか？

単純なエンティティトランスレータを使用して、DTOの値を「実際の」サーバー側のビジネスオブジェクトにマップするWebサービスを作成しました。この演習の一環として。明示的に設定されたnull値と、値を設定していないクライアントとの間に「興味深い」区別があります。

問題は基本的に、クライアントが明示的に値を設定していない場合に実際のビジネスオブジェクトにデフォルト値を設定したいということですが、標準のnull許容型を使用すると、クライアントが明示的に「これをnullに設定」を意味したかどうかを判断する方法がありません。または単にそれを設定しません。

ここでの解決策は、明らかにある種の「フラグ」です。

ビジネスオブジェクト内では、プロパティセッター内に設定されたプライベート「IsDirty」フラグを使用してフィールドの状態を内部的に追跡できますが、DTOは実際にはインターフェイスのみを指定するため、このデータを公開することを意味します。これにより、多くの実装オプションが残ります。言語はC＃（静的に型付けされている）なので...

1. 各プロパティに「IsSet」フラグを公開できますか？
2. 各プロパティを.Valueプロパティと.IsSetプロパティを持つクラスとして公開できますか？などなど。

データ契約でこれらの「フラグ」をどのように公開することを選択しますか？ここでは、このためのベストプラクティスとして何を考えますか？

これについてのご意見をいただければ幸いです。

サービスの参照データに使用する「最適な」パターンに関するフィードバック/オプション/コメントを求める。

参照データとはどういう意味ですか?

例として Northwind を使用してみましょう。Order は、データベース内の Customer に関連付けられています。注文サービスを実装するとき、注文から「完全な」顧客を参照する必要がある場合と、顧客 (キー/値のペアなど) への参照だけが必要な場合があります。

たとえば、GetAllOrders() を実行している場合、完全に入力された Order を返すのではなく、各注文の Customer の参照データのみを含む軽量バージョンの Order を返す必要があります。ただし、GetOrder() メソッドを実行した場合は、このメソッドのコンシューマーが必要とする可能性があるため、顧客の詳細を入力したいと思うでしょう。特定のメソッド呼び出し中に顧客の詳細を入力するように依頼したいが、他の状況では省略したい状況が他にもあるかもしれません。

これが私が思いついたものです：

ここでの考え方は、CustomerDTO では ReferenceInfo (一般的なキーと値のペア) が常に必要であるため、常に ReferenceInfo を保持するということです。後で必要に応じて顧客の詳細を取得するのに十分な情報が得られます。CustomerDTO に ReferenceInfo を要求することの欠点は、完全な CustomerDTO (つまり、CustomerInfo が入力された状態) を取得するときにやり過ぎになる可能性があることですが、少なくとも参照情報は保証されます。

このシナリオ/実装を「よりクリーン」にするために使用できる他のパターンまたはフレームワークの一部はありますか?

私が尋ねる理由は、Northwind では常に完全な CustomerDTO を返すように単純に言うことができますが、Northwind の単純な状況ではうまく機能する可能性があるからです。私の場合、参照/ルックアップ タイプのデータである 25 ～ 50 のフィールドを持つオブジェクトがあります。さまざまな状況で他のものよりもロードすることが重要なものもありますが、これらの参照型の定義をできるだけ少なくしたいと思います (「DTO メンテナンス地獄」に陥らないようにするため)。

意見？フィードバック？コメント?

ありがとう！