2015-05-07 6 views
12

Ich sehe ein seltsames Verhalten in DocumentDB speichern. Ich begann das Speichern von Dokumenten eine einfache alte Klasse verwenden, die so aussah:Sollen meine Azure DocumentDB-Dokumentklassen von Microsoft.Azure.Documents.Document erben?

public class Person 
{ 
    public string Name; 
    public int Age; 
} 

ich diese Dokumente wie folgt gespeichert:

var person = new Person { ... }; 
client.CreateDocumentAsync(myCollectionLink, person); 

Das hat gut funktioniert. Eigenschaften wurden mit genau den Namen in der Klasse gespeichert. Dann erkannte ich, dass ich den Selflink des Dokuments benötigte, um Updates und Löschungen durchzuführen. "Ah", dachte ich. „Ich wurde ableiten nur aus dem Dokument, etwa so:

public class Person: Microsoft.Azure.Documents.Document 
{ 
    public string Name; 
    public int Age; 
} 

jedoch viel zu meiner Überraschung, als ich diese Änderung vorgenommen wurden neue Dokumente vollständig leer erstellt, mit Ausnahme der‚id‘Eigenschaft von DocumentDB zugewiesen selbst .. meine benutzerdefinierte Eigenschaften im Dokument

ich mehrfach doppelt geprüft von Document Ableitung verhindert nicht gespeichert werden ...

... es sei denn, ich ausdrücklich jede mit [JsonProperty] dekorieren, etwa so:

public class Person: Document 
{ 
    [JsonProperty(PropertyName="name")] 
    public string Name; 

    [JsonProperty(PropertyName="age")] 
    public int Age; 
} 

Dann funktioniert es wieder (natürlich unter Verwendung der neuen, mehr JSON-geeigneten camelCase-Eigenschaftsnamen). Nach dem Abruf werden die Objekte mit der SelfLink-Eigenschaft gefüllt, die ich für Aktualisierungen und Löschungen benötige. Alles gut.

Durch meine Fragen sind ... Warum ist das passiert? Mache ich etwas falsch, indem ich von Document ableite? Ihr Feedback würde sehr geschätzt werden.

Antwort

20

Dieses Verhalten wird darauf zurückgeführt, wie JSON.NET mit Eigenschaften dynamischer Objekte umgeht. Es ignoriert sie effektiv, es sei denn, Sie schmücken sie mit dem JsonProperty-Attribut.

Sie können entweder mit reinem POCO arbeiten oder Sie können von Resource (siehe unten), das ein statisches Objekt ist, das Document selbst erweitert, erweitern.

public class Person: Microsoft.Azure.Documents.Resource 
{ 
    public string Name; 
    public int Age; 
} 
+0

Danke, Ryan! Das funktioniert tatsächlich besser. Eine Folgefrage - wird ein bestimmter Ansatz (Dokument + Attribute vs Ressource) als Best Practice bevorzugt? –

+2

Ich habe mich total gerettet. Ich konnte keine Dokumentation wie diese für mein Leben finden. Vielen Dank –

+0

Froh, dass ich das gesehen habe, habe ich meine Haare für eine Stunde gezogen, um herauszufinden, warum das Erben von Document nicht funktionierte. –