ASP.NET MVC C# アプリケーションで複雑なオブジェクト (ネストされたプロパティ、コレクションなど) を使用しています。DB内の複数のテーブルに保存する必要はありません。オブジェクト全体をシリアル化し、全体として保存しても問題ありません。
オブジェクト全体を (JSON/XML のような人間が読める形式で) シリアル化し、DB のテキスト フィールドに格納する予定です。
後でこのオブジェクトを DB からロードし、厳密に型指定されたビューを使用してレンダリングする必要があります。
ここで質問があります。将来、オブジェクトのクラスが変更される可能性があります (フィールドの追加/削除などを行うことができます)。ただし、以前に DB に保存されたシリアル化されたバージョンには変更が反映されません。
これに対処する方法は？
構造化されたシリアル化されたメッセージを大幅に変更するたびに、何らかの変換ユーティリティを作成し、アップグレード プロセスの一部として実行する必要があります。null 許容のフィールドを追加または削除することは問題になりそうにありませんが、より大きな構造上の変更が必要になります。
IXmlSerializable を実装し、メッセージを覗き込んでメッセージのバージョンを把握し、適切に変換することもできますが、これを何度も行う必要があり、アプリケーションのライフサイクルが長い場合、これはすぐに混乱を招きます。そのため、アップグレード プロセスの前に、アプリケーションの外で行う方がよいでしょう。
アップグレードの一部として多くのレコードで変換を実行することに不安がある場合は、より効率的にする方法を考え出すことができます (たとえば、メッセージ スキーマ バージョンを含むテーブルに列を追加して、古くなったメッセージを効率的にターゲットにします)。
JSON または XML を使用している限り、追加されたフィールドは問題になりません (特定のバージョン スキーマが適用されない限り)。たとえば、既定の .net XML シリアライザーには、既定値を持つフィールドは含まれません。 (System.Component.DefaultValue 属性で設定できます)。したがって、新しいフィールドは、デシリアライズ中に省略されたフィールドと同じように扱われ、デフォルト値を取得します (デフォルトのクラス値、つまり、DefaultValue 属性はシリアライゼーション/デザイナーの動作にのみ適用されます)。削除されたフィールドは逆シリアル化の実装によって異なりますが、無視されるようにすることができます。個人的には、プロパティを保持する傾向がありますが、それらがかつて何のためにあったかを示すメッセージを付けて、それらを古いものとしてマークします。そうすれば、コーディング時にそれらを使用しないことがわかります。ただし、下位互換性のためにまだ埋めることができます (また、古いものとしてマークされている場合はシリアル化しないでください)。可能であれば、更新されたデータ構造を埋める古いプロパティにロジックを実装できます。