シリアライゼーションは、依存性注入の使用を排除しますか？

簡単な質問：C＃でのシリアル化にはデフォルトのコンストラクターが必要であることを理解しています。これは、コンストラクターで注入されたDIを使用する可能性を排除します（これは、私の読みでは、一般的に好ましいスタイルのDI ^{です[引用が必要]}）。それは本当にどちらか一方の状況ですか、それとも何か不足していますか？

（サイド質問）：IoCコンテナーはこのトレードオフをどうにかして回避しますか？

標準のシリアル化メカニズムを使用して、C＃の1つのステップで、オブジェクトを逆シリアル化し、別の既存のオブジェクトに依存関係を注入することはできません。代わりにプロパティインジェクションを使用する必要があります。まずデシリアライザを使用してオブジェクトを作成し、その後依存関係をインジェクトします。ほとんどの実際のアプリケーションでは、これが本当の欠点であることは考慮していません。シリアライズ可能なデータモデルクラスがあり、他の非データモデルクラスにも依存している場合は、データモデルクラスにすでに多くの責任。

それが本当に気になる場合は、シリアライザブルオブジェクトをデコレータクラスでラップすることを検討してください。デシリアレータクラスと追加の依存関係をコンストラクタに渡すことができます。そのラッパーは、コンストラクターで2つのステップ（ラップされたオブジェクトの逆シリアル化とプロパティインジェクション）を実行します。

私はこのような問題を解決しています。依存関係のファクトリーを注入することです。これらのファクトリーでは、まずコンテナーに登録されている依存関係を解決し、次に残りのすべてのデータを「非直列化」します。json.netを使用すると、既存のオブジェクトのフィールドにデータを設定できます。

工場のコードはIoCコンテナーの配線コードと一緒なので、container.Resolveファクトリー内での使用はルールに違反しないと思いcontainerます。これは、コード内の1か所でのみ使用する必要があります。

今のところ、リフレクションを使用してこのプロセスを自動化しようと試みています（私がそのアプローチをテストしてきたものとは対照的です）。はい、json.netの逆シリアル化自体に残っているものは多くありません。その一部はカスタムコードで置き換えられますが、なぜわざわざそうなのでしょう。

また、この件に関する最終的な考えや決定は何でしたか？この投稿を読んだ後、2つの方法を確認します。または注入してから、逆シリアル化（設定）します。そして、私はまだ自分の道がより良いと思っています。これに反対する議論を聞いて喜んでいます（私の考えでは、私の場合は私の方法の方が良いかもしれませんが、それが失敗した場合のちょっとした推測だけで、良い代替案をはっきりと想像することはできません）。