2017-02-05 3 views
0

Ich habe ObjectModel, das zum Beispiel enthält, 2 Klasse Student und Kurs.DocumentDB mit Sammlung und Dokument zu Objekt

Ich möchte DocumentDB für das Speichern dieser 2 Sammlung verwenden (eine Sammlung für Kurse und eine für Studenten) Ich muss 2 verschiedene Sammlung in meiner DocumentDB DB erstellen? , Oder darf ich nur eine Sammlung verwenden?

Ein anderes Problem, wenn ich von Dokument zu ObjectModel.Student konvertieren möchte, möchte ich nicht dynamisches Casting (Echtzeit-Performance-Problem) verwenden.

public static async Task<ObjectModel.Student> GetGroupAsyncByID(string id) 
    { 
     try 
     { 
      Document document = await _client.ReadDocumentAsync(UriFactory.CreateDocumentUri(cDatabaseId, cAllCollections[0], id)); 
      return (ObjectModel.Student)document; // compile error 
     } 
     catch (DocumentClientException e) 
     { 
      if (e.StatusCode == System.Net.HttpStatusCode.NotFound) 
      { 
       return null; 
      } 
      else 
      { 
       throw; 
      } 
     } 
    } 

Mein Student Class

public class Student 
    { 
     #region Fields 
     [JsonProperty(PropertyName = "id")] 
     public string ID { get; set; } 
     public String StudentName { get; set; } 

} 

Wie ich von Doucment zu Studenten Objekt werfen können?

Danke!

Antwort

0

DocumentDB ist Schema-Agonostic und ja, Sie können sowohl Kurs-und Student-Objekt in einer Sammlung speichern. Um leicht zu bestimmen, in welche Klasse das Dokument umgewandelt werden soll, können Sie beispielsweise die Eigenschaft "Typ" in beiden Objekten und 1 für das Objekt Kurs und 2 für das Objekt Student definieren.

Das Document-Objekt implementiert den Dynamikkontrakt. Sie können nach Student s = (Dynamik) -Dokument in Student umwandeln. Die Performance-Implikation ist hier sehr gering, da das Dokument bereits das PropertyBag des JSON-Objekts enthielt, es wird lediglich die Eigenschaft von "Student" auf den Wert in PropertyBag gesetzt.

Wenn Sie dies selbst behandeln möchten, stellen ResourceResponse auch den rohen Stream zur Verfügung, sodass Sie die Deserialisierung selbst durchführen können.

+0

Nicht sicher, ich würde vorschlagen, eine '1' und' 2' für 'Type', es sei denn, Sie aus irgendeinem Grund normalisieren (aber es scheint wie eine vorzeitige Optimierung für mich). Geh einfach mit 'Course' und' Student'. –

+0

@Ming Liu basiert auf einem einfachen Test, dynamische Casting ist etwa 20-mal langsamer als statische reguläre C#! Zusätzlich Wenn ich jede Eigenschaft auf meinen ursprünglichen Eigenschaftstyp umsetze, ist es sehr teuer in der Bedeutung der Rechenzeit (von String zu meinem ursprünglichen Typ). DocumentDB speichert das Dokument nicht im Binärformat (wie mongoDB bson). Darf ich etwas vergessen? – mak

Verwandte Themen