Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. tiré de Lignes directrices de conception de framework : Conventions, Idiomes et Modèles pour les bibliothèques .NET réutilisables, 2ème édition. Cette édition a été publiée en 2008, et le livre a été entièrement révisé dans la troisième édition. Certaines informations de cette page peuvent être obsolètes.
La sérialisation est le processus de conversion d’un objet dans un format qui peut être facilement persistant ou transporté. Par exemple, vous pouvez sérialiser un objet, le transporter sur Internet à l’aide de HTTP et le désérialiser sur l’ordinateur de destination.
Le .NET Framework offre trois technologies de sérialisation principales optimisées pour différents scénarios de sérialisation. Le tableau suivant répertorie ces technologies et les principaux types de framework associés à ces technologies.
| Nom de la technologie | Types principaux | Scénarios |
|---|---|---|
| Sérialisation du contrat de données | DataContractAttribute DataMemberAttribute DataContractSerializer NetDataContractSerializer DataContractJsonSerializer ISerializable |
Persistance générale services web JSON |
| Sérialisation XML | XmlSerializer | Format XML avec contrôle total sur la forme du code XML |
| Sérialisation du runtime (binaire et SOAP) | SerializableAttribute ISerializable BinaryFormatter SoapFormatter |
Communication à distance .NET |
✔️ Pensez à la sérialisation lorsque vous concevez de nouveaux types.
Choix de la technologie de sérialisation appropriée pour prendre en charge
✔️ ENVISAGEZ de prendre en charge la sérialisation des contrats de données si des instances de votre type doivent être conservées ou utilisées dans les services web.
✔️ ENVISAGEZ de prendre en charge la sérialisation XML au lieu de ou en plus de la sérialisation du contrat de données si vous avez besoin d’un contrôle supplémentaire sur le format XML généré lors de la sérialisation du type.
Cela peut être nécessaire dans certains scénarios d’interopérabilité où vous devez utiliser une construction XML qui n’est pas prise en charge par la sérialisation du contrat de données, par exemple pour produire des attributs XML.
✔️ ENVISAGEZ de prendre en charge la sérialisation du runtime si des instances de votre type doivent se déplacer entre les limites de communication à distance .NET.
❌ ÉVITEZ de prendre en charge la sérialisation du runtime ou la sérialisation XML uniquement pour des raisons de persistance générales. Préférez la sérialisation des contrats de données à la place.
Prise en charge de la sérialisation des contrats de données
Les types peuvent prendre en charge la sérialisation du contrat de données en appliquant le DataContractAttribute type et les DataMemberAttribute membres (champs et propriétés) du type.
✔️ ENVISAGEZ de marquer les membres de données de votre type public si le type peut être utilisé dans une approbation partielle.
En toute confiance, les sérialiseurs de contrat de données peuvent sérialiser et désérialiser des types et des membres non publics, mais seuls les membres publics peuvent être sérialisés et désérialisés dans une approbation partielle.
✔️ Implémentez un getter et un setter sur toutes les propriétés qui ont DataMemberAttribute. Les sérialiseurs de contrat de données nécessitent à la fois le getter et le setter pour que le type soit considéré comme sérialisable. (Dans .NET Framework 3.5 SP1, certaines propriétés de collection peuvent être get-only.) Si le type ne sera pas utilisé dans une approbation partielle, l’un ou les deux accesseurs de propriété peuvent être non publics.
✔️ ENVISAGEZ d’utiliser les rappels de sérialisation pour l’initialisation des instances désérialisées.
Les constructeurs ne sont pas appelés lorsque les objets sont désérialisés. (Il existe des exceptions à la règle. Les constructeurs de collections marquées avec CollectionDataContractAttribute sont appelés lors de la désérialisation.) Par conséquent, toute logique qui s’exécute pendant la construction normale doit être implémentée comme l’un des rappels de sérialisation.
OnDeserializedAttribute est l’attribut de rappel le plus couramment utilisé. Les autres attributs de la famille sont OnDeserializingAttribute, OnSerializingAttributeet OnSerializedAttribute. Ils peuvent être utilisés pour marquer les rappels qui sont exécutés avant la désérialisation, avant la sérialisation et enfin, après la sérialisation, respectivement.
✔️ ENVISAGEZ d’utiliser la KnownTypeAttribute méthode pour indiquer des types concrets qui doivent être utilisés lors de la désérialisation d’un graphique d’objet complexe.
✔️ Envisagez la compatibilité descendante et vers l’avant lors de la création ou de la modification de types sérialisables.
N’oubliez pas que les flux sérialisés de futures versions de votre type peuvent être désérialisés dans la version actuelle du type, et vice versa.
Veillez à comprendre que les membres de données, même privés et internes, ne peuvent pas modifier leurs noms, types ou même leur ordre dans les versions ultérieures du type, sauf si des précautions particulières sont prises pour préserver le contrat à l’aide de paramètres explicites aux attributs de contrat de données.
Testez la compatibilité de la sérialisation lors de modifications apportées aux types sérialisables. Essayez de désérialiser la nouvelle version dans une ancienne version, et vice versa.
✔️ ENVISAGEZ d’implémenter IExtensibleDataObject pour autoriser l’aller-retour entre différentes versions du type.
L’interface permet au sérialiseur de s’assurer qu’aucune donnée n’est perdue pendant l’aller-retour. La IExtensibleDataObject.ExtensionData propriété est utilisée pour stocker toutes les données de la version ultérieure du type inconnu de la version actuelle, et elle ne peut donc pas la stocker dans ses membres de données. Lorsque la version actuelle est sérialisée et désérialisée ultérieurement dans une version ultérieure, les données supplémentaires seront disponibles dans le flux sérialisé.
Prise en charge de la sérialisation XML
La sérialisation des contrats de données est la technologie de sérialisation principale (par défaut) dans le .NET Framework, mais il existe des scénarios de sérialisation de contrat de données qui ne prennent pas en charge la sérialisation des contrats de données. Par exemple, il ne vous donne pas un contrôle total sur la forme de XML produite ou consommée par le sérialiseur. Si un tel contrôle précis est nécessaire, la sérialisation XML doit être utilisée et vous devez concevoir vos types pour prendre en charge cette technologie de sérialisation.
❌ ÉVITEZ de concevoir vos types spécifiquement pour la sérialisation XML, sauf si vous avez une raison très forte de contrôler la forme du code XML produit. Cette technologie de sérialisation a été remplacée par la sérialisation du contrat de données décrite dans la section précédente.
✔️ ENVISAGEZ d’implémenter l’interface IXmlSerializable si vous souhaitez encore plus de contrôle sur la forme du CODE XML sérialisé que ce qui est proposé en appliquant les attributs de sérialisation XML. Deux méthodes de l’interface et ReadXmlWriteXml, vous permettent de contrôler entièrement le flux XML sérialisé. Vous pouvez également contrôler le schéma XML généré pour le type en appliquant le XmlSchemaProviderAttribute.
Prise en charge de la sérialisation du runtime
La sérialisation du runtime est une technologie utilisée par la communication à distance .NET. Si vous pensez que vos types seront transportés à l’aide de la communication à distance .NET, vous devez vous assurer qu’ils prennent en charge la sérialisation du runtime.
La prise en charge de base de la sérialisation du runtime peut être fournie en appliquant les SerializableAttributescénarios , et des scénarios plus avancés impliquent l’implémentation d’un modèle sérialisable runtime simple (implémenter ISerializable et fournir un constructeur de sérialisation).
✔️ ENVISAGEZ de prendre en charge la sérialisation du runtime si vos types seront utilisés avec la communication à distance .NET. Par exemple, l’espace System.AddIn de noms utilise la communication à distance .NET, et tous les types échangés entre System.AddIn les compléments doivent donc prendre en charge la sérialisation du runtime.
✔️ ENVISAGEZ d’implémenter le modèle serializable runtime si vous souhaitez contrôler complètement le processus de sérialisation. Par exemple, si vous souhaitez transformer des données à mesure qu’elles sont sérialisées ou désérialisées.
Le modèle est très simple. Il vous suffit d’implémenter l’interface ISerializable et de fournir un constructeur spécial utilisé lorsque l’objet est désérialisé.
✔️ Faites en sorte que le constructeur de sérialisation soit protégé et fournissez deux paramètres typés et nommés exactement comme indiqué dans l’exemple ici.
[Serializable]
public class Person : ISerializable
{
protected Person(SerializationInfo info, StreamingContext context)
{
// ...
}
}
✔️ Implémentez explicitement les ISerializable membres.
✔️ Appliquez une demande de lien à l’implémentation ISerializable.GetObjectData . Cela garantit que seul le cœur entièrement approuvé et le sérialiseur runtime ont accès au membre.
Portions © 2005, 2009 Microsoft Corporation. Tous les droits réservés.
Réimprimé par l’autorisation de Pearson Education, Inc. tiré de Framework Design Guidelines : Conventions, Idioms et Patterns pour les bibliothèques .NET réutilisables, 2e édition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la Série de développement Microsoft Windows.