2

Compact Framework の普及レイヤーを実装しました ( BinaryFormatter-like シリアライザーを含む)。必要に応じて、ラムダやイテレータなどの結果としてコンパイラが生成したクラスをシリアル化できるようにしたいと考えています。シリアライズ可能なオブジェクトのイベントに追加され、閉じられたすべての変数がシリアライズ可能である場合、結果のオブジェクト グラフは依然として完全にシリアライズ可能です。

これらのクラスのインスタンスが、シリアル化されたバイナリのビルドとまったく同じビルドによってのみ逆シリアル化できる場合は許容されます。アプリケーションが予期せず終了した場合、普及層は主に耐久性を提供するためのものです (電源障害とデバイスの再起動は別の可能性です)。であり、シリアル化されたデータ ストリームは、前方互換性も後方互換性も期待されていません。さらに言えば、同じソース コードの 2 つのコンパイル間での互換性も期待されていません。結果のすべては、次にサーバーと対話するときにサーバーに送信されます。 、切断中は更新しません。

この限られたコンテキストで、フォーマッタがコンパイラによって生成されたこれらのクラスをシリアル化可能であるかのように扱うことは合理的ですか? 私が見る唯一の代替手段は、シリアル化可能性が懸念されるあらゆる場所で、そうでなければコンパイラがサポートするパターンを手動で実装することです。結果は、過度に冗長なものからほとんど読めないものまでさまざまです。

4

1 に答える 1

2

私はあなたが何を得ているのか分かりますが、私の経験では、dataのシリアル化に集中し、おそらくローカル CQRS キューなどを使用して、既知の状態にロールバック/フォワードすることで耐久性を処理することをお勧めします。 「どうやってそこにたどり着いたか」を保存する方法。

特定の質問については、質問の狭い範囲内(同じビルドでのみ作業するなど)で問題ないと思いますが、それらの変数キャプチャされたものに意味のあるシリアライゼーションがないかどうかに大きく依存します-つまり、this再構築できないUI 要素 (目に見えない で誤ってキャプチャされやすい) (OS ハンドルなど)。それが分離されたデータである場合 (つまり、グラフは独自のコード内からの単なるデータであり、管理されていない依存関係はありません)、問題ないと思います。

もう 1 つの問題は、フル フレームワークで利用できる強力なリフレクションの多くが CF に欠けていることです。これにより、通常のフレームワークよりも扱いにくくなる可能性があります (GetUninitializedObjectたとえば)。おそらく実行可能ですが、もう少し作業が必要です。

于 2011-01-19T08:21:02.897 に答える