Best practice per serializzare / persistere entità del dizionario degli oggetti stringa

3

Sto notando una tendenza verso l'uso di un dizionario di stringa su oggetto (o talvolta stringa su stringa), invece di oggetti strongmente tipizzati. Ad esempio, il nuovo progetto Katana fa un uso pesante di IDictionary<string,object> . Questo approccio evita la necessità di aggiornare continuamente le proprie classi di entità / DTO e le tabelle del database che le persistono con nuove proprietà. Evita anche la necessità di creare nuovi tipi di entità derivate per supportare nuovi tipi di entità, dal momento che il Dizionario è abbastanza flessibile da memorizzare proprietà arbitrarie.

Ecco un esempio forzato:

class StorageDevice { 
    public int Id { get; set; } 
    public string Name { get; set; }
}

class NetworkShare : StorageDevice {
    public string Path { get; set; }
    public string LoginName { get; set; }
    public string Password { get; set; }
}

class CloudStorage : StorageDevice {
    public string ServerUri { get; set }
    public string ContainerName { get; set; }
    public int PortNumber { get; set; }
    public Guid ApiKey { get; set; }
}

vs

class StorageDevice {         
    public IDictionary<string, object> Properties { get; set; }
} 

Fondamentalmente sono alla ricerca di discussioni, libri o articoli su questo approccio, così posso cogliere le migliori pratiche / difficoltà da evitare. Ecco le mie domande principali:

  • Questo approccio ha un nome? (L'unica cosa che ho sentito usare fino ad ora è "oggetti che si autodefiniscono")
  • Quali sono le migliori pratiche per mantenere questi dizionari in un database relazionale? Soprattutto le sfide della deserializzazione con linguaggi strongmente tipizzati come C #.
  • Cambia qualcosa se alcuni degli oggetti nel dizionario sono essi stessi elenchi di entità strongmente tipizzate?
  • Si dovrebbe utilizzare un secondo dizionario se si desidera archiviare temporaneamente oggetti che non devono essere persistenti / serializzati su una rete, o si dovrebbe usare un qualche tipo di namespaces sui tasti per indicare questo?
posta Mark Heath 07.11.2013 - 14:43
fonte

3 risposte

1

Se stai adottando questo approccio, perché seguire un database relazionale tradizionale? I database NoSQL come MongoDB consentono di applicare "schemi sfocati" ai dati che dovrebbero consentire a diverse versioni del software di individuare i documenti che si aspetta e lascia fuori gli altri (o riempilo di null)

    
risposta data 09.11.2013 - 03:34
fonte
1

Probabilmente dovresti prendere questa decisione basandoti sul tuo modello di dati attuale. Se è relativamente statico, penso che faresti meglio a cambiare il tuo schema e ad aggiornare le tue classi e DTO. Potrebbe sembrare un sacco di lavoro, ma se sei C # e Sql land probabilmente alla fine avrai una soluzione migliore.

Potresti anche considerare un approccio ibrido in cui la maggior parte delle tue proprietà è strongmente tipizzata, ma anche un dizionario per più proprietà dinamiche o sparse.

Idealmente, per ottenere una buona soluzione per la tua situazione, dovresti passare a un database di linguaggio dinamico o senza schemi o entrambi.

    
risposta data 09.11.2013 - 14:44
fonte
0

IL MIO approccio (al momento) è JSON.NET per (De) Serializzare ... per ulteriori informazioni vedere link

.. & Linq to JSON per l'interrogazione del JSON se trovi la necessità di farlo.

JSON.NET sembra abbastanza performante e affidabile per serializzare un sacco di Dictionary<string, object> di cose in colonne di testo SQLite nel mio caso d'uso. Il mio caso d'uso è <string,string> al suo livello più basso.

Utilizzare dizionari con indicizzatori di classe ti dà uno pseudo stile di proprietà senza schema per l'indirizzamento delle cose ... Class["key"].Object.Property . Se si archiviano le proprietà dell'oggetto come Dictionary<string,string> e si incorpora quel dizionario in una nuova classe come proprietà, si ottiene una sintassi come Class["key"]["Object"].Value . L'altro vantaggio derivante dall'uso dell'indicizzatore è che è possibile programmare la protezione contro la normale esecuzione di Eccezioni, null, colpi-e -misses ecc. che ottieni con i dizionari. Sono ancora dizionari in modo da poter contare su di essi e su tutti questi tipi di cose.

    
risposta data 08.07.2017 - 08:39
fonte

Leggi altre domande sui tag