Inconvénients de marquer une classe comme Serializable

Question

Quels sont les inconvénients de marquer une classe comme sérialisable?

Je dois sauvegarder ma session asp.net dans une base de données et cela nécessite que les objets de la session soient sérialisables.

Avoir du sens.

Mais il s'avère que tout ce que j'avais à faire était de décorer cette classe avec l'attribut [Serializable] et ça a fonctionné, ce qui signifie que .NET a déjà l'infrastructure sous-jacente pour rendre les classes sérialisables. Alors pourquoi ne peut-il pas le faire par défaut?

Quel est le besoin de le marquer comme tel?

Answer 1

Alors pourquoi ne peut-il pas le faire par défaut?

La sérialisation/désérialisation automatique pourrait ne pas suffire pour l'objet. Par exemple, l'objet pourrait contenir un champ qui contient le nom d'un fichier local, un pointeur vers la mémoire, un index dans un tableau partagé, etc. Alors que le système pourrait généralement sérialiser ces valeurs brutes sans problème, la désérialisation pourrait facilement donner quelque chose d'inutilisable. En général, il est impossible pour le système de comprendre cela seul. En vous obligeant à marquer la classe avec Serializable, vous indiquez que vous avez pris en compte ces considérations.

Answer 2

En termes d'inconvénients, le principal désavantage de la sérialisation est le surcoût de performance (à la fois CPU et disque) et les problèmes de latence potentiels lors de son envoi sur le réseau. Il peut y avoir de légères inquiétudes en matière de sécurité car en général, la sérialisation XML est peu sécurisée puisqu'elle ne fonctionne que sur des propriétés et des classes publiques, vous obligeant dans certains cas à exposer des propriétés que vous n'auriez pas autrement. Bien sûr, si la sécurité est vraiment un problème, vous ne stockeriez probablement pas de données trop sensibles en session.

Si vous utilisez Silverlight, un inconvénient potentiel est que Silverlight ne prend pas en charge l'attribut [Sérialisable], donc toutes les classes décorées avec celui-ci seraient inutilisables pour vos assemblages Silverlight.

Cela étant dit, pour la gestion de session, les petits objets stockés dans la base de données ASPState fonctionnent généralement très bien sans aucune différence notable par rapport à la session en mémoire. À l'opposé de l'échelle, j'ai eu de gros objets avec des listes d'autres objets en propriétés, etc., et s'ils sont suffisamment importants, le surcoût de performance peut être parfois perceptible.