Directrices de serialización

Debe considerar la posibilidad de serializar al diseñar nuevas clases porque una clase no se puede serializar después de haberla compilado. En este punto, surgen algunas cuestiones como las siguientes: ¿Es necesario enviar esta clase a través de dominios de aplicación? ¿Se utilizará esta clase con interacción remota? ¿Qué van a hacer los usuarios con esta clase, deberían derivar una nueva clase que se deba serializar? Cuando tenga dudas, marque la clase como serializable. Probablemente es mejor marcar todas las clases como serializables a menos que alguna de estas afirmaciones sea verdadera:

• La clase nunca va a pasar de un dominio de aplicación a otro. Si la serialización no es necesaria y la clase debe cruzar un dominio de aplicación, derive la clase de MarshalByRefObject.
• La clase almacena punteros especiales que sólo son aplicables a la instancia actual de la clase. Si, por ejemplo, una clase contiene memoria no administrada o controladores de archivos, asegúrese de marcar estos archivos como NonSerialized, o no serialice la clase.
• Los miembros de datos de la clase contienen información confidencial. En este caso, es recomendable marcar la clase como serializable, pero marcar los miembros de datos individuales que contienen información confidencial como NonSerialized. Otra alternativa es implementar la interfaz ISerializable y serializar solamente los campos necesarios.

Tenga en cuenta las implicaciones de seguridad derivadas de marcar una clase como serializable. Una petición de vínculo o una petición de herencia para un permiso CodeAccessPermission en una clase o en un constructor de clases o la serialización personalizada que implementa una petición correspondiente para el mismo permiso CodeAccessPermission pueden pasarse por alto de forma predeterminada. Si una clase tiene una petición de vínculo para un permiso, el motor de tiempo de ejecución comprueba únicamente el llamador inmediato para verificar que el llamador tiene garantizado el permiso. El código de la biblioteca de clases de .NET Framework está firmado con el nombre seguro de Microsoft y siempre tiene garantizada una confianza total. Cualquier código puede utilizar código que tenga garantizada una confianza total para pasar por alto comprobaciones de seguridad en tiempo de enlace. Por ejemplo, en el caso de la serialización, el código malicioso que no posee el permiso de serialización requerido puede llamar a uno de los formateadores de confianza total de .NET Framework, como BinaryFormatter y pasar por alto la comprobación de petición de vínculo para el permiso.

Vea también

Serialización binaria | Acceso a objetos de otros dominios de aplicación mediante .NET Remoting | Serialización XML y SOAP | Seguridad y serialización