12
votes

Interfaces sérialisées

J'essaie de lancer un code similaire à celui-ci: XXX

Est-ce que quelqu'un peut m'expliquer ce que je fais mal?

Je reçois un:

ne peut pas sérialiser un membre .. myarray ... parce qu'il s'agit d'une interface.

ne devrait pas la résoudre x / p>


1 commentaires

Quiconque a dit quelque chose de désérialisant ...?


4 Réponses :


17
votes

Non. Vous ne pouvez pas sérialiser une interface. Déjà. Cela vient de vous dire ça.

Une interface n'est rien de plus qu'une description d'un ensemble de comportements. Il ne dit rien sur le contenu d'une instance. En particulier, bien qu'une instance d'une classe mettant en œuvre une interface doit mettre en œuvre tous ses membres, elle aura certainement des propriétés qui doivent être sérialisées.

Comment cela serait-il désérialisé?

Quelle classe serait utilisée pour désérialiser l'interface de l'autre côté?


8 commentaires

@Shahar: Oui. Ne faire ça. Utilisez un type de béton, pas une interface.


Comment serait-il désérialisé? En tant qu'instance de la classe qui a été sérialisée, de la même manière que la liste . Quelle classe serait utilisée pour désérialiser l'interface de l'autre côté? Voir la première réponse.


Mais comment l'autre partie saura-t-elle quelle classe a été sérialisée? Serait-ce même savoir quelle classe?


@John Saunder Je serais fortement en désaccord avec votre déclaration. Prenons par exemple un cas classique d'interface ishape et de rectangle, cercle la mise en œuvre et MyObject qui a une référence à Ishape. Maintenant et si je dois avoir MyObject sérialisable? "Ne le fais pas" Simple n'a aucun sens, car ma structure de classe doit suivre certains principes de conception généraux, ce qui implique également d'utiliser des interfaces. Je ne veux pas avoir de mauvais design simplement parce que je ne peux pas sérialiser des interfaces et des énoncés comme "ne fais pas ça", car la sérialisation vient seconde après la bonne conception, imo.


Si votre application nécessite une série de sérialisation, concevez votre application pour exiger des classes qui peuvent être sérialisées ne seraient pas une bonne conception. Si vous avez besoin de sérialisation, vous devez concevoir, par exemple, une "couche de persistance" qui inclut des classes pouvant être sérialisées. La partie principale de votre application peut continuer à utiliser des références à des interfaces. Traduire et vers la saveur de "persistance" si nécessaire pour persister (Serialize).


En outre, je n'ai jamais dit "ne le fais pas". J'ai dit "tu ne peux pas le faire".


@Johnsaunders, votre premier paragraphe était juste lorsque vous avez dit "tu ne peux pas le faire". Tout ce que vous avez dit essayait de justifier pourquoi cela devrait être le cas. Ces justifications sont faux. Prenez une interface et remplacez-la par une classe abstraite sans membres. Cela ne change pas le fonctionnement du code du tout. Soudain, vous pouvez le sérialiser!


De plus, vous avez dit «ne faites pas cela», dans votre commentaire ci-dessus.



0
votes

Vous avez inclus Typeof (liste <...>), mais myarray est de type IList <...> qui n'est pas une structure de données apparente elle-même mais plus d'un espace réservé à prendre une structure de données.

Changer le type de myarray à un type spécifique (comme liste, par exemple) et il devrait fonctionner. xxx


0 commentaires

16
votes

Voici une solution de contournement ombragée non testée que j'ai tendance à utiliser en principe:

private IList<Class2> myArray;
[XmlIgnore]
public IList<Class2> MyArray
{
    get { return myArray; }
    set { myArray = value; }
}

[XmlElement("MyArray")]
public object MyArraySerializable
{
    get { return MyArray; }
    set { MyArray = value as IList<Class2>; }
}


1 commentaires

Amen. Le sérieliseur est stupide quand il s'agit de cela! Merci pour le travail autour. Il est beaucoup préférable d'utiliser des interfaces car l'héritage est limité à une classe de base.



10
votes

ou utilisez le DatacontractSerializer à la place.


1 commentaires