0

WCF を使用してクライアント/サーバー、UI/データベース レイヤーを実行することを考えています。WCF サービスを使用して DataRow を読み取り、クラスのプロパティを入力してから、それを UI クライアントに返すことを考えています (これはWindows エンドツーエンド)。

DLL 内のクラスから始めて、UI とサーバーの間で DLL を共有しました。サーバーは DataRow を読み取り、クラスは DataRow からデータを取り込む方法を認識します。このクラスには、プライベート バッキング変数を持つパブリック プロパティがありますが、DataRow から値を設定する場合、クラスはバッキング変数に直接書き込みます。その後、クラスのインスタンスが UI に戻されます。

UI はクラスを逆シリアル化します。クラスにはパブリック プロパティがあり、セッターはすべてバインディングをサポートするために INotifyPropertyChanged を実行します。これまでのところ、正常ではありません。

[DataContract] 属性と [DataMember] 属性から始めましたが、オブジェクトのインスタンスが UI で逆シリアル化されると、クラスのインスタンスのパブリック プロパティ セッターが呼び出されることに気付きました。 ' 各プロパティのイベント。

それを回避するために、IXmlSerializer を使用できることを読みました。そこで、属性を削除し、IXmlSerializer インターフェイスをサポートし、ReadXml() メソッドを使用して、パブリック プロパティの背後にあるバッキング変数に直接書き込みました。

これはすべて正常に機能します (パラメーターなしのコンストラクターが必要になったことを除いて) が、合理的ですか? これは物事がどのように機能するはずですか?

UI からは INotifyPropertyChanged を認識し、サーバー エンドからは DataRow から自身を構築する方法を認識している共有クラスを持たないでください。そのロジックをすべて別の場所に置き、 XSD を使用してクラスを定義する必要がありますか?

問題は、私が遭遇した問題 (null 許容型を逆シリアル化する方法など) をおそらく解決できることですが、より良い方法がないことは確かではありません。Windows から Windows への WCF 通信以外をサポートする必要性は予見できないので、XML がどのように見えるか (または XML が存在するかどうか) は実際には気にしません。

ポインタをいただければ幸いです。

ありがとう。

4

1 に答える 1

0

考えられる解決策の 1 つは、サーバー側でコントラクト ([DataContract]、[DataMember] を介してシリアル化可能) を維持し、クライアント側でエンティティを維持することです。特定のサービス メソッドはコントラクトを返しますが、サービスを直接呼び出すことはありません。代わりに、プロキシを中間に配置します。プロキシはサービス メソッドを呼び出し、コントラクトからエンティティに変換してから、エンティティを返します。

このように、フロント エンドはそのエンティティのみに関心があり (プロキシとのみ対話し、サービスと直接対話することはないため)、コントラクトについてまったく心配する必要がありません。そして、独自のファンキーなシリアライゼーションを行う必要はありません:)

于 2012-09-27T21:11:19.197 に答える