Casting interfaces pour la désérialisation de JSON.NET

Je suis en train de mettre en place un lecteur qui se tiendra dans les objets JSON à partir de différents sites web (pensez à l'information de grattage) et de les traduire en objets C#. Je suis actuellement en utilisant JSON.NET pour le processus de désérialisation. Le problème, je suis en cours d'exécution, c'est qu'il ne sait pas comment gérer l'interface des propriétés de niveau dans une classe. Donc, quelque chose de la nature:

public IThingy Thing

Produira l'erreur:

Impossible de créer une instance de type IThingy. Le Type est une interface ou une classe abstraite et ne peut pas être instanciée.

Il est relativement important d'avoir un IThingy par opposition à un Truc depuis le code, je suis en train de travailler sur sont considérées comme sensibles et les tests unitaires est très important. Se moquant des objets atomique des scripts de test n'est pas possible à part entière des objets comme Truc. Ils doivent être d'une interface.

J'ai été penché sur JSON.NET la documentation pour un certain temps maintenant, et les questions que j'ai pu trouver sur ce site ce sont tous de plus d'un an. Toute aide?

Aussi, si il le faut, mon appli est écrit .NET 4.0.

InformationsquelleAutor tmesser | 2011-04-25
  1. 97

    @SamualDavis fourni une excellente solution dans un une question relative à la, que je vais résumer ici.

    Si vous avez désérialiser un flux JSON dans une classe concrète qui a les propriétés de l'interface, vous pouvez inclure les classes concrètes en tant que paramètres à un constructeur de la classe! Le NewtonSoft deserializer est assez intelligent pour comprendre qu'il doit utiliser ces classes concrètes pour désérialiser les propriétés.

    Voici un exemple:

    public class Visit : IVisit
{
    ///<summary>
    ///This constructor is required for the JSON deserializer to be able
    ///to identify concrete classes to use when deserializing the interface properties.
    ///</summary>
    public Visit(MyLocation location, Guest guest)
    {
        Location = location;
        Guest = guest;
    }
    public long VisitId { get; set; }
    public ILocation Location { get;  set; }
    public DateTime VisitDate { get; set; }
    public IGuest Guest { get; set; }
}
    • Comment serait-ce de travailler avec une ICollection? ICollection<IGuest> les Clients{get;set;}
    • Je n'ai pas essayé. Désolé. Si vous avez l'occasion de le vérifier, s'il vous plaît poster ici pour nous le laisser savoir si cela fonctionne.
    • Il fonctionne avec ICollection<ConcreteClass>, donc ICollection<Invité> fonctionne. Juste comme pour info, vous pouvez mettre l'attribut [JsonConstructor] sur votre constructeur de sorte qu'il sera utilisé par défaut si vous arrive d'avoir plusieurs constructeurs
    • Super! Merci pour la vérification de la sortie.
    • Constructeur solution est génial, merci!
    • linq est un raccourci de la méthode de jeter un IEnumerable et il a travaillé pour moi. Ex) Clients = clients.Cast<IGuest>();
    • Je suis coincé au même problème, dans mon cas, j'ai plusieurs de la mise en œuvre de l'interface ( dans votre exemple, l'interface est ILocation ) donc si il y a des classes comme MyLocation, VIPLocation, OrdinaryLocation. Comment cartographier l'Emplacement de la propriété ? Si vous avez juste une mise en œuvre comme MyLocation il est facile, mais comment le faire si il y a plusieurs implémentations de ILocation ?
    • Je n'ai pas essayé moi-même, mais il ressemble à Eric Boumendil la réponse peut vous orienter vers une solution. Bonne chance!
    • Le constructeur version fonctionne très bien, mais j'ai dû enlever le constructeur sans paramètre au sein de la classe (ou au moins modifier sa visibilité à l '"intérieur" ou similaire) pour faire ce travail.
    • Si vous avez plus d'un constructeur, vous pouvez marquer votre spécial constructeur avec la [JsonConstructor] attribut.
    • Ce n'est pas bien du tout. Le point de l'utilisation des interfaces est d'utiliser l'injection de dépendance, mais de le faire avec un objet typé paramètre requis par votre constructeur, vous totalement à vis, au point d'avoir une interface comme une propriété.
    • Cela n'a pas de résoudre mon problème, mais il ne la rendre ÉVIDENTE que j'avais oublié de mettre en œuvre une interface sur un des types que j'essayais de désérialiser. Belle astuce!
    • pour vous, -1 pour la réponse. Il me stupéfie combien de personnes font des choses comme celles-ci.
    • Je suis en désaccord. Ce n'est pas à la défaite de l'injection de dépendances à tous. Vous pouvez également ajouter un autre constructeur qui prend les interfaces comme arguments, ou un constructeur par défaut qui ne prend pas d'arguments à tous. Ensuite, il n'y a pas de condition que ces classes spécifiques à être utilisé lors de l'instanciation de l'objet. Mais avoir ce constructeur permet le deserializer à comprendre ce que les classes à utiliser. Aussi, , un des les points de disposer d'interfaces est l'injection de dépendance. Ce n'est certainement pas le seul cas dans lequel les interfaces sont utiles.

    InformationsquelleAutor Mark Meuer
  2. 48

    (Copié à partir de cette question)

    Dans le cas où je n'ai pas eu de contrôle sur les entrants JSON (et ne peut donc pas s'assurer qu'il comprend un $type de propriété) j'ai écrit un convertisseur personnalisé qui permet de spécifier explicitement le type de béton:

    public class Model
{
    [JsonConverter(typeof(ConcreteTypeConverter<Something>))]
    public ISomething TheThing { get; set; }
}

    Ce n'utilise la valeur par défaut processus de mise en œuvre de Json.Net tout en spécifiant explicitement le type de béton.

    Une vue d'ensemble sont disponibles sur ce blog. Source code est ci-dessous:

    public class ConcreteTypeConverter<TConcrete> : JsonConverter
{
    public override bool CanConvert(Type objectType)
    {
        //assume we can convert to anything for now
        return true;
    }

    public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
    {
        //explicitly specify the concrete type we want to create
        return serializer.Deserialize<TConcrete>(reader);
    }

    public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
    {
        //use the default serialization - it works fine
        serializer.Serialize(writer, value);
    }
}
    • J'aime vraiment cette approche et de l'appliquer à notre propre projet. J'ai même ajouté un ConcreteListTypeConverter<TInterface, TImplementation> pour gérer les membres de la classe de type IList<TInterface>.
    • C'est un peu beaucoup de code. Il pourrait être plus agréable d'avoir le code pour concreteTypeConverter dans la question.
    • Vous pouvez poster votre ConcreteListTypeConverter<TInterface, TImplementation> mise en œuvre?
    • Et si vous avez deux réalisateurs de ISomething?
    InformationsquelleAutor Steve Greatrex
  3. 41

    Pourquoi utiliser un convertisseur? Il y a une fonctionnalité native dans Newtonsoft.Json pour résoudre ce problème exact:

    Ensemble TypeNameHandling dans le JsonSerializerSettings à TypeNameHandling.Auto

    JsonConvert.SerializeObject(
        toSerialize,
        new JsonSerializerSettings()
        {
          TypeNameHandling = TypeNameHandling.Auto
        });

    Mets de chaque type dans le json, qui n'est pas considéré comme un béton instance d'un type, mais comme une interface ou une classe abstraite.

    Je l'ai testé et il fonctionne comme un charme, même avec des listes.

    Source et un autre manuel de mise en œuvre: Code À L'Intérieur De Blog

    • Parfait, cela m'a aidé pour un quick & sale profonde clone ( stackoverflow.com/questions/78536/deep-cloning-objects )
    • Qui était-il! Quelle est la différence entre Objects et Auto tho?
    • Objets: "Comprennent les .NET type de nom lors de la sérialisation d'un objet JSON structure." Auto: Inclure l' .NET type de nom lorsque le type de l'objet sérialisé n'est pas le même que son type déclaré. Notez que ceci n'inclut pas la racine de l'objet sérialisé par défaut. Pour inclure la racine de l'objet nom de type JSON, vous devez spécifier un type de racine objet avec SerializeObject(Objet, le Type, la JsonSerializerSettings) ou Serialize(JsonWriter, Objet, Type)." Source: newtonsoft.com/json/help/html/...
    • Meilleure réponse quand les Types sont des "vert-champ" / auto contrôlée. Merci!
    • J'ai juste essayé ce sur la Désérialisation et il ne fonctionne pas. La ligne d'objet de ce Débordement de Pile question est, "Coulée interfaces pour la désérialisation de JSON.NET"
    • il ne fonctionne que lorsque le json a été sérialisé avec le même réglage
    • Celui-ci devrait être la bonne réponse comme il le soutien de la désérialisation d'une interface en plus d'une mise en œuvre. dans mon cas, a ajouté ce réglage sur la fonction de désérialisation
    • Si vous utilisez le Newtosoft bibliothèque c'est de loin le plus propre approche parmi les proposés.
    • Upvote pour le rapide, si ce n'est pas sale, de solution. Si vous venez de la sérialisation de configurations, cela fonctionne. Beats arrêt de développement pour construire des convertisseurs et certainement beaucoup mieux que de décorer chaque injecté de la propriété. sérialiseur.TypeNameHandling = TypeNameHandling.Auto; JsonConvert.DefaultSettings().TypeNameHandling = TypeNameHandling.Auto;
    • Ceci est valide et la bonne chose quand les données json est sérialisé et désérialisé par la même application, mais si vous recevez externe json puis il ne fonctionne pas bien
    • qui est correct.

    InformationsquelleAutor Mafii
  4. 36

    Pour activer la désérialisation de plusieurs implémentations d'interfaces, vous pouvez utiliser JsonConverter, mais pas par le biais d'un attribut:

    Newtonsoft.Json.JsonSerializer serializer = new Newtonsoft.Json.JsonSerializer();
serializer.Converters.Add(new DTOJsonConverter());
Interfaces.IEntity entity = serializer.Deserialize(jsonReader);

    DTOJsonConverter cartes de chaque interface avec une mise en œuvre concrète:

    class DTOJsonConverter : Newtonsoft.Json.JsonConverter
{
    private static readonly string ISCALAR_FULLNAME = typeof(Interfaces.IScalar).FullName;
    private static readonly string IENTITY_FULLNAME = typeof(Interfaces.IEntity).FullName;


    public override bool CanConvert(Type objectType)
    {
        if (objectType.FullName == ISCALAR_FULLNAME
            || objectType.FullName == IENTITY_FULLNAME)
        {
            return true;
        }
        return false;
    }

    public override object ReadJson(Newtonsoft.Json.JsonReader reader, Type objectType, object existingValue, Newtonsoft.Json.JsonSerializer serializer)
    {
        if (objectType.FullName == ISCALAR_FULLNAME)
            return serializer.Deserialize(reader, typeof(DTO.ClientScalar));
        else if (objectType.FullName == IENTITY_FULLNAME)
            return serializer.Deserialize(reader, typeof(DTO.ClientEntity));

        throw new NotSupportedException(string.Format("Type {0} unexpected.", objectType));
    }

    public override void WriteJson(Newtonsoft.Json.JsonWriter writer, object value, Newtonsoft.Json.JsonSerializer serializer)
    {
        serializer.Serialize(writer, value);
    }
}

    DTOJsonConverter est nécessaire uniquement pour les deserializer. Le processus de sérialisation est inchangé. L'objet Json n'avez pas besoin d'intégrer des types de béton noms.

    Ce DONC, après les propose la même solution une étape plus loin avec un générique JsonConverter.

    • Ne serait-ce pas WriteJson méthode de l'appel à sérialiseur.Sérialiser provoquer un débordement de pile, depuis l'appel de sérialiser sur la valeur sérialisée par le convertisseur serait la cause du convertisseur WriteJson méthode à appeler de nouveau de manière récursive?
    • Il ne faut pas, si l'CanConvert () la méthode retourne un résultat cohérent.
    • Pourquoi êtes-vous en comparant FullNames lorsque vous pouvez simplement comparer directement les types?
    • Une simple comparaison de types aussi est très bien.
    InformationsquelleAutor Eric Boumendil
  5. 10

    L'utilisation de cette classe, pour la cartographie de type abstrait de type réel:

    public class AbstractConverter<TReal, TAbstract> : JsonConverter where TReal : TAbstract
{
    public override Boolean CanConvert(Type objectType) 
        => objectType == typeof(TAbstract);

    public override Object ReadJson(JsonReader reader, Type type, Object value, JsonSerializer jser) 
        => jser.Deserialize<TReal>(reader);

    public override void WriteJson(JsonWriter writer, Object value, JsonSerializer jser) 
        => jser.Serialize(writer, value);
}

    ...et quand désérialiser:

            var settings = new JsonSerializerSettings
        {
            Converters = {
                new AbstractConverter<Thing, IThingy>(),
                new AbstractConverter<Thing2, IThingy2>()
            },
        };

        JsonConvert.DeserializeObject(json, type, settings);
    • J'aime vraiment une belle concise réponse qui résout mon problème. Pas besoin de autofac ou quoi que ce soit!
    • Je pense, est une bonne réponse pour mon cas.
    • Il vaut la peine de mettre de ce le convertisseur déclaration de classe: where TReal : TAbstract pour s'assurer qu'il peut lancer le type
    • Une information plus complète où peut-être where TReal : class, TAbstract, new().
    • J'ai utilisé ce convertisseur avec struct trop, je crois "où TReal: TAbstract" est suffisant. Merci à tous.
    • De l'or! La nappe de chemin à parcourir.
    • Grand. Cette solution, contrairement à la accepté de répondre, fonctionne également si vous ne pouvez pas modifier la classe réelle et la nécessité de mettre en œuvre l'interface vous-même.

    InformationsquelleAutor Gildor
  6. 6

    J'ai trouvé cela utile. Vous pourriez aussi.

    Exemple D'Utilisation

    public class Parent
{
    [JsonConverter(typeof(InterfaceConverter<IChildModel, ChildModel>))]
    IChildModel Child { get; set; }
}

    De Création Personnalisé Convertisseur

    public class InterfaceConverter<TInterface, TConcrete> : CustomCreationConverter<TInterface>
    where TConcrete : TInterface, new()
{
    public override TInterface Create(Type objectType)
    {
        return new TConcrete();
    }
}

    Json.NET la documentation

    • Pas une solution viable. N'a pas de Listes d'adresses et conduit à l'aspersion décorateurs/annotations partout.
    InformationsquelleAutor smiggleworth
  7. 5

    Deux choses que vous pourriez essayer:

    Mettre en œuvre un try/parse modèle:

    public class Organisation {
public string Name { get; set; }
[JsonConverter(typeof(RichDudeConverter))]
public IPerson Owner { get; set; }
}
public interface IPerson {
string Name { get; set; }
}
public class Tycoon : IPerson {
public string Name { get; set; }
}
public class Magnate : IPerson {
public string Name { get; set; }
public string IndustryName { get; set; }
}
public class Heir: IPerson {
public string Name { get; set; }
public IPerson Benefactor { get; set; }
}
public class RichDudeConverter : JsonConverter
{
public override bool CanConvert(Type objectType)
{
return (objectType == typeof(IPerson));
}
public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
{
//pseudo-code
object richDude = serializer.Deserialize<Heir>(reader);
if (richDude == null)
{
richDude = serializer.Deserialize<Magnate>(reader);
}
if (richDude == null)
{
richDude = serializer.Deserialize<Tycoon>(reader);
}
return richDude;
}
public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
{
//Left as an exercise to the reader :)
throw new NotImplementedException();
}
}

    Ou, si vous pouvez le faire dans votre modèle d'objet, de mettre en œuvre un béton de classe de base entre IPerson et votre feuille d'objets, et désérialiser à elle.

    Le premier peut éventuellement échouer au moment de l'exécution, la seconde nécessite des modifications à votre modèle d'objet et homogénéise la sortie vers le plus petit dénominateur commun.

    • Un try/parse modèle n'est pas faisable en raison de l'échelle que j'ai à travailler avec. J'ai d'envisager une portée de plusieurs centaines d'objets de base avec encore plus des centaines de stub/helper objets pour représenter intégré objets JSON qui arrive souvent. Il n'est pas hors de question de changer de modèle d'objet, mais ne serait pas à l'aide d'un béton de classe de base dans les propriétés de nous rendre incapables de se moquer des éléments pour les tests unitaires? Ou suis-je arriver que vers l'arrière en quelque sorte?
    • Vous pouvez toujours mettre en œuvre une maquette de IPerson - à noter que le type de l'Organisation.Propriétaire de la propriété est encore IPerson. Mais pour la désérialisation d'un arbitraire de cible, vous devrez retourner un type concret. Si vous ne possédez pas de la définition de type et vous ne pouvez pas définir l'ensemble minimal de propriétés de votre code, il faudra, ensuite, votre dernier recours est quelque chose comme une clé/valeur sac. À l'aide de votre facebook exemple comment - pouvez-vous poster en réponse à ce que votre (une ou plusieurs) des implémentations de ILocation ressembler? Qui peut aider à faire avancer les choses.
    • Depuis la la primaire de l'espoir est moqueur, la ILocation interface est, vraiment, simplement une façade pour l'Emplacement de l'objet concret. Un exemple rapide, j'ai juste travaillé jusqu'serait quelque chose comme ceci (pastebin.com/mWQtqGnB) pour l'interface (pastebin.com/TdJ6cqWV) de l'objet concret.
    • Et pour aller à la prochaine étape, c'est un exemple de ce que IPage ressemblerait (pastebin.com/iuGifQXp) et (pastebin.com/ebqLxzvm). Le problème, bien sûr, étant que, même si la désérialisation de Page serait généralement bien fonctionner, il va s'étouffer quand il arrive à l'ILocation de la propriété.
    • Ok, donc la réflexion sur les objets que vous êtes réellement en grattant et la désérialisation - c'est généralement le cas que les données JSON est cohérent avec une seule concrète la définition de la classe? Sens (en théorie), vous ne rencontrerez pas des "lieux" avec des propriétés supplémentaires qui ferait Lieu impropre à l'utilisation en tant que le béton type de l'objet désérialisé? Si oui, l'attribution de la ILocation propriété de la Page avec un "LocationConverter" devrait fonctionner. Si non, et c'est parce que les données JSON n'est pas toujours conforme à la rigide ou une structure cohérente (comme ILocation), puis (... suite)
    • (... suite) ensuite, j'ai besoin de plus d'infos. Quel usage voulez-vous ILocation fournir? Représente-t-il le "minimum requis" champs de votre système a besoin? Ou tout simplement des champs vous avez l'habitude de rencontrer? Si c'est le dernier, et vous ne vous attendez pas à chaque champ sur chaque objet, avez-vous considéré nullable champs ou une clé/valeur de recherche pour le stockage de ces champs à la place?
    • Vous mentionnez l'échelle et donc, ce que je demandais, c'est si votre problème est peut être de la variabilité de la structure des données. Ce que vous pourriez aussi regarder, puisque vous utilisez le framework 4.0, sont les types de dynamiques. Plus précisément, vous pouvez jeter un oeil à ceci: amazedsaint.com/2010/02/.... Vous pourrait avoir Lieu hériter ElasticObject mais encore être extensible pour plus de propriétés. Mais vous auriez encore besoin d'un convertisseur de mise en œuvre pour chaque classe de béton, afin d'obtenir la statique de propriétés de l'interface en plus de la dynamique des champs.

    InformationsquelleAutor mcw0933
  8. 4

    Pour ceux qui pourraient être curieux de connaître les ConcreteListTypeConverter qui a été référencé par Oliver, voici ma tentative:

    public class ConcreteListTypeConverter<TInterface, TImplementation> : JsonConverter where TImplementation : TInterface 
{
public override bool CanConvert(Type objectType)
{
return true;
}
public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
{
var res = serializer.Deserialize<List<TImplementation>>(reader);
return res.ConvertAll(x => (TInterface) x);
}
public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
{
serializer.Serialize(writer, value);
}
}
    • Je suis confondu avec le substituée CanConvert(Type objectType) { return true;}. Il semble hacky, comment exactement est-ce utile? J'ai peut-être tort, mais ce n'est pas que l'envie de raconter une petite inexpérimenté de chasse qu'ils vont gagner le combat peu importe l'adversaire?
    InformationsquelleAutor Matt M
  9. 4

    Nicolas Westby a fourni une excellente solution dans un article génial.

    Si vous voulez de la Désérialisation JSON à l'une des nombreuses classes qui implémentent une interface de ce genre:

    public class Person
{
public IProfession Profession { get; set; }
}
public interface IProfession
{
string JobTitle { get; }
}
public class Programming : IProfession
{
public string JobTitle => "Software Developer";
public string FavoriteLanguage { get; set; }
}
public class Writing : IProfession
{
public string JobTitle => "Copywriter";
public string FavoriteWord { get; set; }
}
public class Samples
{
public static Person GetProgrammer()
{
return new Person()
{
Profession = new Programming()
{
FavoriteLanguage = "C#"
}
};
}
}

    Vous pouvez utiliser un JSON personnalisé converter:

    public class ProfessionConverter : JsonConverter
{
public override bool CanWrite => false;
public override bool CanRead => true;
public override bool CanConvert(Type objectType)
{
return objectType == typeof(IProfession);
}
public override void WriteJson(JsonWriter writer,
object value, JsonSerializer serializer)
{
throw new InvalidOperationException("Use default serialization.");
}
public override object ReadJson(JsonReader reader,
Type objectType, object existingValue,
JsonSerializer serializer)
{
var jsonObject = JObject.Load(reader);
var profession = default(IProfession);
switch (jsonObject["JobTitle"].Value())
{
case "Software Developer":
profession = new Programming();
break;
case "Copywriter":
profession = new Writing();
break;
}
serializer.Populate(jsonObject.CreateReader(), profession);
return profession;
}
}

    Et vous aurez besoin pour décorer la "Profession" de la propriété avec un JsonConverter attribut de le faire savoir à l'utilisation de votre convertisseur personnalisé:

        public class Person
{
[JsonConverter(typeof(ProfessionConverter))]
public IProfession Profession { get; set; }
}

    Et ensuite, vous pouvez lancer votre classe avec une Interface:

    Person person = JsonConvert.DeserializeObject<Person>(jsonString);
    InformationsquelleAutor A. Morel
  10. 3

    Supposons qu'un autofac réglage comme suit:

    public class AutofacContractResolver : DefaultContractResolver
{
private readonly IContainer _container;
public AutofacContractResolver(IContainer container)
{
_container = container;
}
protected override JsonObjectContract CreateObjectContract(Type objectType)
{
JsonObjectContract contract = base.CreateObjectContract(objectType);
//use Autofac to create types that have been registered with it
if (_container.IsRegistered(objectType))
{
contract.DefaultCreator = () => _container.Resolve(objectType);
}  
return contract;
}
}

    Ensuite, supposons que votre classe est comme ceci: 

    public class TaskController
{
private readonly ITaskRepository _repository;
private readonly ILogger _logger;
public TaskController(ITaskRepository repository, ILogger logger)
{
_repository = repository;
_logger = logger;
}
public ITaskRepository Repository
{
get { return _repository; }
}
public ILogger Logger
{
get { return _logger; }
}
}

    Par conséquent, l'utilisation de l'outil de résolution dans la désérialisation pourrait être:

    ContainerBuilder builder = new ContainerBuilder();
builder.RegisterType<TaskRepository>().As<ITaskRepository>();
builder.RegisterType<TaskController>();
builder.Register(c => new LogService(new DateTime(2000, 12, 12))).As<ILogger>();
IContainer container = builder.Build();
AutofacContractResolver contractResolver = new AutofacContractResolver(container);
string json = @"{
'Logger': {
'Level':'Debug'
}
}";
//ITaskRespository and ILogger constructor parameters are injected by Autofac 
TaskController controller = JsonConvert.DeserializeObject<TaskController>(json, new JsonSerializerSettings
{
ContractResolver = contractResolver
});
Console.WriteLine(controller.Repository.GetType().Name);

    Vous pouvez voir plus de détails dans http://www.newtonsoft.com/json/help/html/DeserializeWithDependencyInjection.htm

    • Je vais jusqu'-vote, c'est la meilleure solution. DI a été si largement utilisé à ce jours en c# les développeurs web, et cela convient bien comme un lieu centralisé pour gérer ce type de conversion par le solveur.
    InformationsquelleAutor OmG
  11. 2

    Pour ce que ça vaut, j'ai fini par avoir à gérer de cette me pour la plupart. Chaque objet a une Deserialize(string jsonStream) méthode. Quelques extraits de celui-ci:

    JObject parsedJson = this.ParseJson(jsonStream);
object thingyObjectJson = (object)parsedJson["thing"];
this.Thing = new Thingy(Convert.ToString(thingyObjectJson));

    Dans ce cas, nouveau Truc(string) est un constructeur qui fera appel à la Deserialize(string jsonStream) méthode du type de béton. Ce régime va continuer à aller vers le bas et vers le bas jusqu'à arriver à la base de points que json.NET pouvez simplement gérer.

    this.Name = (string)parsedJson["name"];
this.CreatedTime = DateTime.Parse((string)parsedJson["created_time"]);

    Ainsi de suite et ainsi de suite. Cette configuration m'a permis de donner json.NET des configurations, il peut gérer sans avoir à refactoriser une grande partie de la bibliothèque elle-même ou à l'aide de lourdes essayer/analyser des modèles qui s'enlisent l'ensemble de notre bibliothèque en raison du nombre d'objets impliqués. Cela signifie aussi que je peux gérer tout json changements sur un objet spécifique, et je n'ai pas besoin de vous inquiéter de tout ce que l'objet touche. Ce n'est pas la solution idéale, mais il fonctionne très bien à partir de notre unité et de tests d'intégration.

    InformationsquelleAutor tmesser
  12. 2

    Plusieurs années et j'ai eu un problème similaire. Dans mon cas n'ont été fortement imbriqués les interfaces et une préférence pour générer les classes concrètes au moment de l'exécution, de sorte qu'Il serait de travailler avec une classe générique.

    J'ai décidé de créer une classe proxy au moment de l'exécution qui encapsule l'objet renvoyé par Newtonsoft.

    L'avantage de cette approche est qu'il ne nécessite pas une mise en œuvre concrète de la classe et peut gérer n'importe quelle profondeur d'imbrication des interfaces automatiquement. Vous pouvez en savoir plus à ce sujet sur mon blog.

    using Castle.DynamicProxy;
using Newtonsoft.Json.Linq;
using System;
using System.Reflection;
namespace LL.Utilities.Std.Json
{
public static class JObjectExtension
{
private static ProxyGenerator _generator = new ProxyGenerator();
public static dynamic toProxy(this JObject targetObject, Type interfaceType) 
{
return _generator.CreateInterfaceProxyWithoutTarget(interfaceType, new JObjectInterceptor(targetObject));
}
public static InterfaceType toProxy<InterfaceType>(this JObject targetObject)
{
return toProxy(targetObject, typeof(InterfaceType));
}
}
[Serializable]
public class JObjectInterceptor : IInterceptor
{
private JObject _target;
public JObjectInterceptor(JObject target)
{
_target = target;
}
public void Intercept(IInvocation invocation)
{
var methodName = invocation.Method.Name;
if(invocation.Method.IsSpecialName && methodName.StartsWith("get_"))
{
var returnType = invocation.Method.ReturnType;
methodName = methodName.Substring(4);
if (_target == null || _target[methodName] == null)
{
if (returnType.GetTypeInfo().IsPrimitive || returnType.Equals(typeof(string)))
{
invocation.ReturnValue = null;
return;
}
}
if (returnType.GetTypeInfo().IsPrimitive || returnType.Equals(typeof(string)))
{
invocation.ReturnValue = _target[methodName].ToObject(returnType);
}
else
{
invocation.ReturnValue = ((JObject)_target[methodName]).toProxy(returnType);
}
}
else
{
throw new NotImplementedException("Only get accessors are implemented in proxy");
}
}
}
}

    Utilisation:

    var jObj = JObject.Parse(input);
InterfaceType proxyObject = jObj.toProxy<InterfaceType>();
    • Merci! C'est la seule réponse la prend correctement en charge le typage dynamique (duck-typing) sans imposer de restrictions sur les entrants json.
    • Pas de problème. J'ai été un peu surpris de voir qu'il y avait rien. Il a évolué un peu depuis que l'exemple d'origine j'ai donc décidé de partager le code. github.com/sudsy/JsonDuckTyper . J'ai aussi publié sur nuget comme JsonDuckTyper. Si vous trouvez que vous souhaitez l'améliorer, il suffit de m'envoyer un PR et je serai heureux d'obliger.
    • Quand j'étais à la recherche d'une solution dans ce domaine, je suis tombé sur github.com/ekonbenefits/impromptu-interface aussi. Il ne fonctionne pas dans mon cas car il ne prend pas en charge dotnet core 1.0, mais il pourrait fonctionner pour vous.
    • J'ai essayé avec l'Impromptu de l'Interface, mais Json.Net n'était pas content de faire une PopulateObject sur le proxy généré par l'Impromptu de l'Interface. Je n'ai malheureusement abandonné aller pour le Duck-Typing - c'était plus facile de créer un personnalisé Json Contrat Sérialiseur que l'habitude de la réflexion afin de trouver une implémentation de l'interface demandée et en les utilisant.
    InformationsquelleAutor Sudsy
  13. 1

    Aucun objet ne jamais être un IThingy que les interfaces sont toutes, par définition, abstrait.

    L'objet que vous avez qui a d'abord été sérialisé est béton type, la mise en œuvre de la résumé interface. Vous avez besoin d'avoir cette même béton classe de relancer les données sérialisées.

    L'objet résultant sera alors de quelque type que implémente la résumé interface vous êtes à la recherche pour.

    De la la documentation il s'ensuit que vous pouvez utiliser

    (Thingy)JsonConvert.DeserializeObject(jsonString, typeof(Thingy));

    lors de la désérialisation d'informer JSON.NET sur le type de béton.

    • C'est précisément le post de plus d'un an que je faisais référence. La seule grande suggestion (écriture personnalisé convertisseurs) n'est pas vraiment possible avec l'échelle, je suis forcé de prendre en compte. JSON.NET a beaucoup changé au cours de l'année. J'ai parfaitement comprendre la distinction entre une classe et une interface, mais C# prend également en charge les conversions implicites à partir d'une interface d'un objet qui implémente l'interface à l'égard de la saisie. Je suis de renvoi demande en substance si il y a une façon de dire JSON.NET l'objet d'implémenter cette interface.
    • Il était là dans la réponse que je vous ai cité. Assurez-vous que il ya une _type propriété qui signale le type de béton à utiliser.
    • Et je doute fort que C# supporte n'importe quel type de "implicites" typecasting à partir d'une variable déclarée comme une interface à un type de béton sans aucune sorte de trucs.
    • Sauf si j'ai lu qu'il est mauvais, le _type de la propriété était censé être dans le JSON pour être sérialisé. Cela fonctionne bien si vous êtes seulement de la désérialisation ce que vous avez déjà activé, mais ce n'est pas ce qui se passe ici. Je suis en tirant JSON à partir d'un certain nombre de sites qui ne sont pas va être la suite de cette norme.
    • Avez-vous contrôler à la fois la sérialisation et la désérialisation de la source JSON? Parce que finalement, vous aurez besoin pour intégrer le type de béton dans le JSON sérialisé comme une allusion à utiliser lors de la désérialisation ou vous aurez besoin d'utiliser une sorte d'essayer/parse modèle qui détecte/tente de détecter le type de béton à l'exécution et à l'appeler approprié deserializer.
    • Puis il suffit d'ajouter le _type de propriété pour le JSON avant de vous désérialisez - c'est une opération simple.. Et je suis à peu près certain que JSON.NET vous permet de spécifier le béton Type pour relancer l'objet avec.
    • Je ne suis pas 100% sûr de ce que tu veux dire par "contrôler" la (dé)sérialisation, mais notre code sera de faire les deux si c'est ce que vous demandez. L'obstacle est que nous allons être en tirant dans beaucoup de JSON à partir de sites qui ne sont pas affiliées à celui que je suis en train de construire, ce qui fait que nous n'arrivons pas à contrôler.
    • href="http://james.newtonking.com/projects/json/help/html/M_Newtonsoft_Json_JsonConvert_DeserializeObject_1.htm" >james.newtonking.com/projects/json/help/html/.... Comme je l'ai dit, il est facile de spécifier le béton type lors de la désérialisation.
    • Ce n'est pas aussi simple que vous le faites pour être depuis JSON que vous obtenez dans le même problème que beaucoup de convertisseurs/JSON raclant les classes comme vous le faites d'objets. Le facebook de l'API est un bon exemple de la façon dont vous ne pouvez pas simplement présumer un type d'objet par le nom de la variable parce que plusieurs objets, utilisez le même nom pour complètement différentes structures.
    • Qui est pourquoi vous avez la _type allusion... Est-il si difficile de faire comprendre? Si vous avez le nom de l'interface dans le JSON, puis ont afunction qui peut l'inspecter et le retour de la Type de sorte qu'il peut être utilisé par DeserializeObject. Dans l'ensemble, il y a plusieurs façons de le faire - c'est loin d'être difficile.
    • Juste pour s'assurer que je suis ce que vous êtes suggérant, vous recommandez réglage individuel deserializers sur chaque objet, la recherche de JSON pour ces objets internes, et à les traiter un par un avec JsonConvert.DeserializeObject?
    • Vous avez besoin d'une recherche entre quelle que soit l'interface JSON est marqué et le type de béton maintenant, n'est-ce pas? Vous ne vous attendez pas le code, par magie, en déduire tout cela par lui-même avez-vous?
    • Mais pour obtenir quelque chose de droite - est-ce la désérialisation d'un property d'un objet, qui est de type IThingy? Si c'est le cas, alors votre question doit refléter ce que c'est complètement différent de la matière.. Dans ce cas, la chose la plus sûre serait de faire juste un /s/IThingy/Thingy sur le JSON pour remplacer les interfaces avec des implémentations concrètes..
    • Je vous serais reconnaissant si vous tomber l'attitude condescendante ou supprimé votre réponse. J'ai très clairement évoqué les problèmes, mais vous semblez déterminé à l'égard de moi comme un imbécile. Cela a conduit à des réponses très peu serviable. _type indicateur est impossible; je ne peut pas déduire les types de noms de variables et n'ont aucun contrôle sur beaucoup de commentaires. Faire interne les appels statiques par objet peut être pratique, mais aussi peut-être un peu moins quand tant de JSON retours sont non-standardisés. Si vous n'êtes pas intéressés à explorer des solutions de rechange et les réponses, s'il vous plaît arrêter d'y répondre.
    • Sean - Oui, c'est une propriété dans une classe. J'ai senti, c'était parfaitement clair entre les " objets à l'intérieur d'une classe de la clause et l'exemple de code, mais je mettrai à jour la question à clarifier.
    • Ne cherche pas à être condescendant, mais le _type soupçon est le résoudre pour vous, et vous semblez être attendre un peu de magie interrupteur qui fera tout pour vous. Une option pourrait être pour décorer le contrat principal avec allusion attributs, quelque chose comme [ConcreateImpl(typeof(Thingy)] Public IThingy Thingy;. Mais: Vous avez un sérieux problème ici - vous que vous disposez de plusieurs types d'objets et de multiples sources, vous n'avez pas le contrôle, et donc aucun moyen d'identifier quel type abstrait n'importe quel morceau de JSON se réfère à... cela signifie que vous ne pouvez pas faire cela, c'est par définition impossible.
    • Mais il y a une solution simple: créer un Type pour la désérialisation qui n'a que le béton des propriétés, ce qui peut être traduit dans une Interface en fonction de l'objet, ou se répartit comme une fonction de la structure de votre code. C'est si vous savez que le type abstrait nécessaires pour relancer les données en premier lieu, vous n'avez pas..
    • Peut-être que je manque quelque chose dans votre _type suggestion, alors. Prenons un exemple pour rendre les choses plus claires. Facebook est une cible facile donc, nous allons essayer ceci: graph.facebook.com/KState. Dans cet exemple, la base serait comme, "page", ou quelque chose. Mon problème est que, pour des fins de test, le "lieu" doit être quelque chose comme type ILocation dans mon code. Je dois tourner le JSON sur cette page en un "page" de l'objet. Comment suis-je censé s'occuper de la _type allusion, exactement, étant donné que l'entrée?
    • Voir hanselman.com/blog/..., à mi-chemin, la partie commençant avec {"__type":"ConsoleApplication1.Person, ConsoleApplication1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
    • Ou voir social.msdn.microsoft.com/Forums/en/asmxandxml/thread/...
    • Votre objet peut jamais de Type ILocation - il peut être d'un Type que implémente ILocation. Vous dites que vous comprenez la différence entre le concret et l'abstrait, mais soit vous ne connaissez pas la bonne terminologie, ou vous n'avez tout simplement pas. Instancier un Emplacement et est respecter le contrat stipulé par ILocation aussi longtemps que l'Emplacement implémente cette interface.

    InformationsquelleAutor Sean Kinsey
  14. 1

    Ma solution à celui-ci, je l'aime, car il est bien général, est comme suit:

    ///<summary>
///Automagically convert known interfaces to (specific) concrete classes on deserialisation
///</summary>
public class WithMocksJsonConverter : JsonConverter
{
///<summary>
///The interfaces I know how to instantiate mapped to the classes with which I shall instantiate them, as a Dictionary.
///</summary>
private readonly Dictionary<Type,Type> conversions = new Dictionary<Type,Type>() { 
{ typeof(IOne), typeof(MockOne) },
{ typeof(ITwo), typeof(MockTwo) },
{ typeof(IThree), typeof(MockThree) },
{ typeof(IFour), typeof(MockFour) }
};
///<summary>
///Can I convert an object of this type?
///</summary>
///<param name="objectType">The type under consideration</param>
///<returns>True if I can convert the type under consideration, else false.</returns>
public override bool CanConvert(Type objectType)
{
return conversions.Keys.Contains(objectType);
}
///<summary>
///Attempt to read an object of the specified type from this reader.
///</summary>
///<param name="reader">The reader from which I read.</param>
///<param name="objectType">The type of object I'm trying to read, anticipated to be one I can convert.</param>
///<param name="existingValue">The existing value of the object being read.</param>
///<param name="serializer">The serializer invoking this request.</param>
///<returns>An object of the type into which I convert the specified objectType.</returns>
public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
{
try
{
return serializer.Deserialize(reader, this.conversions[objectType]);
}
catch (Exception)
{
throw new NotSupportedException(string.Format("Type {0} unexpected.", objectType));
}
}
///<summary>
///Not yet implemented.
///</summary>
///<param name="writer">The writer to which I would write.</param>
///<param name="value">The value I am attempting to write.</param>
///<param name="serializer">the serializer invoking this request.</param>
public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
{
throw new NotImplementedException();
}
}

    }

    Vous pourriez évidemment, et trivialement convertir une convertisseur universel par l'ajout d'un constructeur qui a eu un argument de type Dictionary<, Type> avec pour instancier les conversions variable d'instance.

    InformationsquelleAutor Simon Brooke
  15. 0

    Ma solution a été ajouté les éléments de l'interface dans le constructeur.

    public class Customer: ICustomer{
public Customer(Details details){
Details = details;
}
[JsonProperty("Details",NullValueHnadling = NullValueHandling.Ignore)]
public IDetails Details {get; set;}
}
    InformationsquelleAutor Jorge Santos Neill