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?