问题
Developers have to 'opt in' for making classes serializable by explicitly using SerializableAttribute. What could go wrong if classes were serializable by default?
回答1:
I would assume that classes are not serializable by default because there's no guarantee that a dump of the object's state to a stream using Reflection even makes sense. What if your object holds an open connection to a database or communication port? Whenever a new object was constructed by deserializing an instance of the previous object, you would end up with a useless object.
Plus, you have to consider that whenever a class is serializable, the runtime insists that all of its member variables be serializable as well, unless they are explicitly marked otherwise. It's much easier to make serializability an opt in functionality for developers, rather than forcing them to opt out certain members.
And finally, you might have certain fields in your class that contain private or sensitive information. Having to explicitly mark classes as serializable ensures that you don't accidentally expose the details of something (whether it be the data or your implementation) to the world that you didn't mean to be public.
回答2:
Serializable classes imply that they have some kind of state that can be written to an external location and read again. For a lot of classes that doesn't make any sense at all - what kind of state does a Thread have, that you could successfully serialize?
It's a little bit philosophical but by convention the default type of a class is not serializable, unless you explicitely define "this class can be serialized".
回答3:
IMO [Serializable] is confusing, largely because it is not actually required by most serialization. By that I mean: there is more code using XmlSerializer (includes asmx), DataContractSerializer (includes WCF), JavaScriptSerializer (includes MVC's JsonResult), or things like protobuf-net etc. [Serializable] is mainly BinaryFormatter, which is (from what I see) in definite decline. and with many good reasons.
As for why: other answers address this, but it doesn't always make sense to serialize something. Sure entity objects can act as DTO, but that is hard to detect in a robust way.
So IMO there is negligible impact on whether I is [Serializable] or not, but I do agree with the default: you should know that you are planning to serialize something. In some cases this serialization means extra work (particularly as some serializers don't run the ctor/init code, so you need to know to prepare fields appropriately).
回答4:
The Liskov Substitution Principle implies that if a class is serializable, all derived classes should be serializable as well. If classes were by default serializable, it would be very difficult to derive non-serializable classes without violating the Liskov Substitution Principle.
回答5:
It is probably better to mark all classes as serializable unless:
- They will never cross an application domain. If serialization is not required and the class needs to cross an application domain, derive the class from MarshalByRefObject.
- The class stores special pointers that are only applicable to the current instance of the class. If a class contains unmanaged memory or file handles, for example, ensure these fields are marked as NonSerialized or don't serialize the class at all.
- Some of the data members contain sensitive information. In this case, it will probably be advisable to implement ISerializable and serialize only the required fields.
Ref:Object Serialization in the .NET Framework
来源：https://stackoverflow.com/questions/4408909/why-classes-are-not-serializable-by-default-in-net