c# - クラスをSerializableにしないのはなぜですか？

Question

ビューステートにいくつかのオブジェクトを保存していますが、クラスを作成することに不利な点があるかどうか疑問に思っていましたSerializable。

すべてのクラスを作るのは悪い習慣Serializableですか？

Answer 1

まず第一に。ビューステートは避けてください。

通常、オブジェクトの転送にはシリアル化（テキスト）が使用されます。

DTO（データ転送オブジェクト）またはメッセージクラスではないクラスをシリアル化可能としてマークすることは避けてください。これを行う理由はいくつかあります。シリアル化された形式でクラスを取得するものには、非DTOクラスのメソッド情報（元のアセンブリにある）がない場合があります。次に、クラスがリソース（DB接続、ファイルハンドルなど）を参照する場合があります。明示的に設計されていない限り、シリアル化解除はリソース接続と状態を再確立しないため、これらをシリアル化しないでください。

要約すると、コンテキストメソッドがあり、サードパーティが使用するデータを保存している場合は、シリアル化しないでください。（メソッドを使用したサービス応答のように、悪い考えです）。また、クラスにリソース参照が含まれている場合はシリアル化しないでください。シリアライズ可能なオブジェクトをメソッドから可能な限りクリーンに保ちます。これには、サービスタイプパターンへの少しのリファクタリングが含まれる場合があります。

DTOとメッセージをシリアル化します。

これは、より多くの設計上の選択です。

Answer 2

実際に直列化可能なすべてのクラスをとして作成することをお勧めしSerializableます。私は常識を使用し、プロセスの境界を越えることを目的としたクラス（DTOクラス）に設定します。

つまり、次のようなクラスです。

• それらのプロパティはすべて単純なタイプです
• そして、それらが複雑なプロパティを持っている場合、それらのタイプ自体はシリアル化可能です

Answer 3

[Serializable]を使用する場合は、それを（またはISerializable）としてマークする必要BinaryFormatterがあります。これには、デフォルト構成でのビューステートが含まれる場合があります。良い習慣と悪い習慣については...まあ、ほとんどのクラスはシリアル化する必要はなく、IMOをシリアル化する場合でも、使用することがBinaryFormatter常に最良の選択であるとは限りません*。具体的には、両方としてマークする[Serializable]と[DataContract]、例外IIRCが発生します。

* =実際、IMOBinaryFormatterが良い選択になることはめったにありませんが、偏見があるかもしれません...そして意図的にviewstateを使用しません; p