問題タブ [iserializable]

データ アクセス層、サービス層、およびプレゼンテーション層があります。プレゼンテーション レイヤーは ASP.NET MVC2 RTM (Web) で、サービス レイヤーは WCF (サービス) です。すべて.NET 3.5 SP1です。

問題は、サービスで、返されるオブジェクトが[DataContract]属性でマークされていることです。Web は AppFabric キャッシュ (別名 Velocity) SessionStateProvider を使用してセッション状態を保存しています。このため、セッションに保存するものはすべてシリアライズ可能でなければなりません。

ここで問題が発生します: DataContracts はマークされておらず[Serializable]、私が覚えている限り、すでに[DataContract]いくつかの問題が発生しているクラスに導入することで発生するため、これが解決策であるとは思いません。

私は当初、Web レイヤーで DataContracts を使用することを計画していました。それらを DataContracts のレンダリングに関連するビューのモデルとして使用します (おそらく、より高いレベルの ViewModel クラス内にネストされます)。しかし、セッション状態プロバイダーは、内部に格納されているすべてのオブジェクトをシリアライズ可能にする必要があるため、この戦略を再考し始めています。ただし、インターフェイスを使用した検証ロジックが含まれてIDataErrorInfoおり、同じ検証ロジックをモデル バインディングの一部として MVC で再利用できるため、あると便利です。

必要な作業を減らすことができる最善の方法は何だと思いますか?

私は現在、次のさまざまな方法を考えています。

A. Web プロジェクトで「ServiceIntegration」パーツを作成します。

これは、コントローラーと WCF サービス層の間の仲介者になります。ServiceIntegration 部分は、DataContracts を使用してサービス層と通信し、ViewModels を使用して Web 層と通信しますが、双方向トランスフォーマーを使用して DataContracts と ViewModels の間で変換する必要があります。

また、IDataErrorInfo Validation は再利用できないため、Transformer を使用して ViewModel から DataContract に変換し、IDataErrorInfo を使用して検証を実行し、その結果を返す、DataContract ごとの Validator も作成する必要があります。これは、コントローラーのアクション メソッド内で使用されます (例: if (!MyValidator.IsValid(viewModel)) return View();)

必要なさまざまなクラス: xDataContract、xViewModel、xTransformer、xValidator

B. Web プロジェクトで「SessionIntegration」パーツを作成する

これは、コントローラー (またはセッションにアクセスするもの) とセッション自体の間の仲介者になります。セッションへのアクセスを必要とするものはすべて、このクラスを通過します。DataContracts は、セッションに格納されていない限り、アプリケーション全体で使用されます。SessionIntegration 部分は、DataContract を何らかの ISerializable 形式に変換し、元に戻す責任を負います。DataContract で IDataErrorInfo インターフェイスを使用するため、追加の Validator は必要ありません。

必要なさまざまなクラス: xDataContract、xTransformer、xSerializableForm

注: どちらのシナリオでも ViewModel は存在しますが、(B) を使用すると、DataContract から ViewModel を構成できます。

(B) 追加のバリデーターを必要としないという利点があります。

(A)/(B) を完全に実装する前に、フィードバックをお願いします。現時点では(B)に傾き始めていますが、(A)の方が柔軟かもしれません。いずれにせよ、その価値に対してあまりにも多くの作業が行われているようです。他の誰かがこの問題に遭遇しましたか、私に同意/反対しますか、そして/または問題を解決する他の方法はありますか?

ありがとう、

ジェームズ

WCF メソッドを使用して、かなり一般的なデータ セットを渡したいと考えています。データは基本的にキーと値のペアの階層セットですが、任意のレベルにネストされています。私はもともとそれを単一の文字列として渡し、両端でXMLまたはJSONまたは同様のエンコード/デコードを行うことを検討していましたが、とにかくWCFトランスポートはXMLであるため、少しばかげているように見えたので、渡す方法があることを望んでいます"当然"。

この方法はかなり簡単です。

と：

これはすべて正常にコンパイルされますが、サービスを実行しようとすると、DataContract.GetStableName で StackOverflowException が発生してクラッシュします。

[CollectionDataContract]クラスに属性を付けて、DataTreeすべての名前を明示的に指定しようとしましたが、違いはないようです。

私もそれをつけようとしましたが、 is で[DataContract]あるため、さらに早く失敗します。DictionaryISerializable

何か案は？これを行うより良い方法はありますか？

クラス Foo がマークされ[Serializable]、実装してISerializableいます。DataContractSerializer を介してシリアル化しようとしています。GetObjectData では、次のようにします。

次のエラーで失敗します。

要素 ':Test' には、'http://schemas.microsoft.com/2003/10/Serialization/Arrays:ArrayOfint' データ コントラクトのデータが含まれています。デシリアライザーは、このコントラクトにマップされる型を認識しません。'ArrayOfint' に対応する型を既知の型のリストに追加します。たとえば、KnownTypeAttribute 属性を使用するか、DataContractSerializer に渡される既知の型のリストに追加します。

DataContractSerializer コンストラクターに引数を渡そうとしknownTypesましたが、役に立ちませんでした。

カスタムシリアライゼーションを使用してアプリのデータをシリアライズしています。つまり、保存している各クラスには[Serializable]属性と実装がありますISerializable。シリアル化されているオブジェクト グラフは、オブジェクト/クラス間の相互参照が多く、かなり複雑です。シリアル化は機能しますが、かなり遅いです。:(

関連する各クラスのGetObjectDataメソッドにブレークポイントを設定すると、オブジェクトよりもはるかに多くのヒットが得られることがわかりました。

私は混乱しています - シリアライゼーションフレームワークについての私の理解は、オブジェクトグラフに複数の参照が含まれていても、各オブジェクトを一度だけ保存するというものでした。これは、保存中に各オブジェクトのGetObjectDataメソッドを一度だけ呼び出す必要があることを意味すると思いました。私が間違っている？

もしそうなら、クラスのGetObjectDataメソッドへの呼び出しの数を減らすために、このアプローチでできることはありますか?

ありがとう。

ISerializable でシリアライズ可能/デシリアライズ可能にしたサブクラスを持つカスタム抽象基本クラスがあります。このクラスのサブクラスの単一インスタンスのシリアル化/逆シリアル化を行うと、すべて正常に動作します。ただし、それらの配列を実行すると、逆シリアル化で常に null の配列になります。シリアル化は BinaryFormatter で行われます。

アイテムは次の中に含まれています。

シリアル化では、これは SerializationInfo パラメータの GetObjectData で行われます。

逆シリアル化では、これはシリアル化コンストラクターでも SerializationInfo パラメーターで行われます。

逆シリアル化では常に null の配列が得られます。前述したように、次のコードで 1 つのアイテムを正しくシリアル化および逆シリアル化します。

シリアル化 (GetObjectData メソッド):

逆シリアル化 (シリアル化コンストラクター):

これはよくある問題ですか？少なくとも他の誰かがそれに遭遇したことはないようです。解決策があることを願っています :) より多くの情報/コードを提供する必要がある場合は、教えてください。

ありがとう！

WCF の使用 Silverlight サービスでは、通常、DataContract 属性と Datamember 属性を使用して、何をシリアル化するかを選択します。これは、クライアントとの間で送受信されるものです。ほとんどの場合、これが問題になることはありません。

ただし、Silverlight アプリと共有しようとしているいくつかのクラス、「成熟した」クラスがあり、データがいっぱいのクライアントに送信したいと考えています。これらのクラスは ISerializable を実装していますが、これは、更新時に WCF サービスとうまく連携したくありません。

ISerializable 属性は、他の古いコードで使用されているため、そのままにしておく必要があります。現在、データを転送するための新しいクラスを作成することが最善の選択肢であると考えています。可能な場合は、データを転送するためだけにクラスを作成する必要はありませんが、それが私がしていることだと考えていますしなければならないでしょう。

これをサービスを介してシリアル化し、そこに ISerializable タグを保持できるようにするために私ができることについてのアイデアはありますか?

次の場所に投稿するユーザーと同様の問題が発生しました。

WinForms C＃でのカスタムオブジェクトタイプのクロスプロセスドラッグアンドドロップ

幸い、SortedListオブジェクトを除いて、カスタムオブジェクトのほぼすべての部分をシリアル化する方法を理解しました。

このオブジェクトが必要なのは、アプリケーションにとって非常に重要な情報が含まれており、Xmlのネストがかなり乱雑だからです。

ISerializableメンバーGetObjectData（）にSortedListを追加する行をコメントアウトすると、オブジェクトはそれを新しいアプリに渡します。そのままにしておくと、そうではなく、シリアル化する方法がわかりません。

私はここStackOverflowとWebの両方でいくつか調べましたが、何の役にも立ちませんでした。

次のコードを使用して、オブジェクトがシリアル化可能かどうかを確認し、別のアプリケーションにドラッグアンドドロップできるようにします。

誰かが私を助けることができる提案がありますか？可能であれば、ドラッグアンドドロップ中にXmlNodeのリストをそのまま保持したいのですが、追加のコーディングを行ってシリアル化可能な部分に分割し、反対側で再構築することに反対しません。重要なことは、最終結果にSortedListが含まれている必要があるということです。

必要に応じて、ドラッグアンドドロップ用にシリアル化するカスタムオブジェクトのコンテンツを提供できます。

ありがとう、

カイルK。

DbMetalは、ISerializableインターフェースを実装せず、。でマークされていないクラスを生成することに気づきましたDataContractAttribute。そのようなクラスをシリアル化する最も簡単な方法は何ですか？私を助けることができるDbMetalパラメータはありますか？

NetDataContractSerializerを使用していくつかの.NETオブジェクトをシリアル化し、アプリケーション内でこれらのオブジェクトの状態を記憶する方法としてXMLをデータベースに保存している状況があります。最近、プロパティ名と型名のコードリファクタリングによって、このXMLデータの逆シリアル化に失敗した最初の状況に遭遇しました。

これまでのところ、NetDataContractSerializer自体で利用可能な機能を使用して逆シリアル化を制御するか、XMLを直接変換するなど、バージョンの互換性の侵害に対処する方法について、2つの異なる攻撃計画を考え出しました。私の実験と調査から、カスタムSerializationBinderを使用して別のタイプに逆シリアル化できるようですプロパティ名/タイプの変更は、ISerializableを実装するか、ISurrogateSelectorおよびISerializationSurrogateを実装してシリアル化サロゲートを作成することで対処できます。残念ながら、この優先メカニズムは機能していません。他の方法で表示できない限り、シリアル化されたデータのバージョン間を移動するサロゲートを使用しているように見えます。これは、Microsoftによる説明のつかない設計上の決定によるものです。Microsoftが提案したのは、両側で同じシリアル化を使用することです。これは、型名が変更されたり、別の名前空間またはアセンブリに移動されたりした場合に、サロゲートを使用する目的を完全に無効にします。

これを修正するには、同じNetDataContractSerializerインスタンス、または互換性のあるSurrogateSelectorで初期化された別のインスタンスを使用してください。

この説明は、シリアル化構造の他の変更に対処するとともに、カスタムバインダーを使用して型を置き換えることについて述べているMSDNの記事と矛盾します。

デシリアライズ中に、フォーマッタはバインダーが設定されていることを確認します。各オブジェクトが逆シリアル化されようとしているときに、フォーマッターはバインダーのBindToTypeメソッドを呼び出し、フォーマッターが逆シリアル化するアセンブリ名とタイプを渡します。この時点で、BindToTypeは実際に構築するタイプを決定し、このタイプを返します。

新しいタイプがSerializableカスタム属性を介した単純なシリアル化を使用する場合、元のタイプと新しいタイプはまったく同じフィールド名とタイプである必要があることに注意してください。ただし、新しいバージョンの型はISerializableインターフェイスを実装でき、その特別なコンストラクターが呼び出され、型はSerializationInfoオブジェクトの値を調べて、それ自体を逆シリアル化する方法を決定できます。

したがって、NetDataContractSerializerを機能させてV1 XMLをV2タイプに逆シリアル化できるようにするか、XMLを手動で変換する必要があります。誰かがNetDataContractSerializerのSerializationInfoがISerializableを使用するとき、またはMicrosoftが提供するものよりも優れているか、少なくともより良い説明を与えるシリアル化サロゲートを使用するときに実際に機能することを証明できれば、おそらく新しい質問を投稿して最善の方法を議論します.NETで、古いXMLを直接変換します。

UPDATE 2011-08-16： いくつかの実験の後、シリアル化された元のタイプがISerializableを実装した場合、ISerializableとシリアル化の代理手法の両方が正常に機能するようです。そうでない場合、タイプが[Serializable]属性を使用しただけの場合、オブジェクトの各フィールドが表示されます。グラフには、追加の属性の形式でいくつかの貴重な型情報がありません。

[Serializable]属性の使用例

ISerialzableの実装例：

NetDataContractSerializerとカスタムバインダーを使用してタイプを変更し、そのタイプにISerializableを実装するか、基本的にISerializalbeの役割を果たすシリアル化サロゲートを指定するサロゲートセレクターを提供することで最初の例を逆シリアル化すると、ISerializationSurrogateに空のSerializationInfoが表示されます。 .SetObjectDataメソッド。2番目の例でxmlを処理すると、SerializationInfoは正しい情報を取得しているように見え、期待どおりに機能します。

私の結論は、SerializableAttributeのみを介してシリアル化をサポートする型に対してNetDataContractSerializerによって生成されるデフォルトのXMLは、型情報が不足しているため、ISerializableまたはシリアル化サロゲート手法を使用した逆シリアル化と互換性がないということです。したがって、NetDataContractSerializableをより将来にわたって利用できるようにするには、シリアル化をカスタマイズして、このタイプ情報がXMLに含まれるようにし、ソースXMLを手動で変換せずに後で逆シリアル化をカスタマイズできるようにする必要があります。

ISerializable を実装する場合、このようなコードを記述して、カスタムの逆シリアル化を実行します...

(注: これは些細な例であり、カスタムの逆シリアル化を保証するものではありません)。

インテリセンスのヘルプによれば、逆シリアル化する型を GetValue メソッドに渡す必要があります。

「格納された値をこの型に変換できない場合、システムは System.InvalidCast 例外をスローします」

これは、私のステートメント例で 2 つのキャストが実行されているということですか?

さらに、この型パラメーターを追加するポイントは何ですか。次のように書くと

...「型「オブジェクト」を「文字列」に暗黙的に変換できない」ため、これはとにかくコンパイルされません。したがって、これはとにかくオブジェクトをキャストする必要があることを意味します。したがって、キャストが無効な場合、いずれにしても自分のキャストを介して InvalidCastException を取得します。

ここでは2 つのキャストが発生しているように見えますが、同様に、エラーは実行時にのみ発生する可能性があります (ジェネリックを介して達成できるコンパイル型チェックはありません)。

更新:「is」演算子を使用して型が期待どおりであることを確認する舞台裏である可能性がありますか? 「is」は自動的にキャストを試みますか?