多くの異なる方法 (モード) でシリアライズおよびデシリアライズする必要があるかなり大きなオブジェクト グラフがあります。一部のモードでは、特定のプロパティを逆シリアル化したい場合と、そうでない場合があります。将来のモードでは、プロパティのオプションが yes または no よりも多くなる可能性もあります。問題は、これらのモードをどのように実装するかです。
アプローチ A (逆シリアル化コンストラクターと ISerializable.GetObjectData を使用):
逆シリアル化コンストラクターを使用してグラフの各オブジェクト自体をシリアル化すると、逆シリアル化のさまざまなモードすべてに対して多くのスイッチが得られます。ただし、このアプローチの利点は、すべての逆シリアル化ロジックが 1 つの場所にあることです。新しいプロパティを追加する場合は、ISerializable.GetObjectData と逆シリアル化コンストラクターを変更するだけで済みます。もう 1 つの利点は、公開される可能性のある内部状態をオブジェクトが考慮できることです。最も重要な欠点は、データオブジェクト自体が可能なすべてのシリアル化モードについて知る必要があることです。新しいモードが必要な場合は、データ オブジェクトを変更する必要があります。
アプローチ B (デシリアライゼーション ファクトリ クラス/メソッド):
別のアプローチは、シリアライゼーションとデシリアライゼーションを外部で行うモードごとに、ある種のデシリアライゼーション ファクトリ クラス/メソッドを用意することです (例: GraphSerializer.SerializeObjectTypeX(ObjectTypeX objectToSerialze)。ここでの利点は、新しいモードが必要なときはいつでも新しいFactory Class/Method と Dataobject は、導入されたすべてのシリアライゼーション モードで混乱することはありません. ここでの主な欠点は、すべての異なるモードに対して同じシリアライゼーション コードを何度も書かなければならないことです. 2 つのモードが単に異なる場合1 つまたは 2 つのプロパティですが、グラフ全体の完全なロジックを再度実装する必要があるため、データ オブジェクトに新しいプロパティを追加するときは、すべてのファクトリ クラスを更新する必要があります。
したがって、この IMHO の一般的な問題に対するより良いアプローチがあるのではないかと思います。それとも .NET のベスト プラクティスでしょうか? それとも、間違った視点から全体にアプローチしているだけなのでしょうか?