Progettazione impostazioni di configurazione multiutente

Question

Progettazione impostazioni di configurazione multiutente

#1 da (2 voti)
#2 da (1 voti)
#3 da (-3 voti)

1

Sto progettando un modo flessibile ed estensibile per memorizzare le impostazioni di configurazione per gli utenti.

Progettazione tabella database:

╔═════════════════════════════╗ 
║ ConfigurationItemDefinition ║ 
╠═════════════════════════════╣ 
║ ID                          ║ 
║ Name                        ║ 
║ Type                        ║ 
║ DefaultValue (varchar)      ║ 
║ ConfigurationItemAdapterID  ║ 
╚═════════════════════════════╝ 
              |
╔═══════════════════════════════╗
║ ConfigurationItem             ║
╠═══════════════════════════════╣
║ ID                            ║
║ UserID                        ║
║ ConfigurationItemDefinitionID ║
║ Value (varchar)               ║
╚═══════════════════════════════╝

Spiegazione:

La tabella ConfigurationItemDefinition contiene la definizione per le impostazioni di configurazione. Type è il tipo .NET che il valore verrebbe analizzato / serializzato quando interrogato nel codice.

La tabella ConfigurationItem è dove i valori di configurazione sono impostati per ogni utente . Se non esiste un valore impostato esplicitamente per un utente specifico per una definizione di elemento di configurazione, viene utilizzato il valore DefaultValue da ConfigurationItemDefinition .

ConfigurationItemAdapterID determina quale tecnica deve essere utilizzata per "ottenere" e "impostare" il valore di configurazione. Ad esempio, un valore int userebbe un Parse di base (da string - > int). Un oggetto CultureInfo dovrebbe utilizzare un adattatore di serializzazione. Il modo in cui i valori di configurazione vengono ottenuti e impostati è determinato dall'adattatore (esempi di seguito).

Codice C #

In C #, un'impostazione sarebbe acquisita in questo modo:

// This would use the Parse adapter
int timeout = someUser.GetConfigurationValue<int>("TimeoutValue"); 

// This would use the Serialization adapter
CultureInfo cultureInfo = someUser.GetConfigurationValue<CultureInfo>("CultureInformation");

E imposta come segue:

// This would use the Parse adapter
someUser.SetConfigurationValue<bool>("IsLive", true);

Si prega di criticare questo design. Esistono altri modi standard per affrontare un simile problema?

design c# design-patterns database-design configuration

posta davenewza 12.04.2013 - 08:57

fonte

3 risposte

1

Ho già realizzato soluzioni come questa in passato, ma direi che il progetto proposto è in realtà un anti-pattern del database relazionale poiché memorizzi i dati senza (dal punto di vista del database) la digitazione applicabile. Stai fondamentalmente usando un database relazionale come un archivio di chiavi / valori.

Secondo me, l'uso di tabelle regolari con colonne regolari configurate con tipi di dati corretti per ogni proprietà è più semplice, più gestibile e gioca ai vantaggi del database relazionale che si sta utilizzando. Se ritieni che l'aggiunta o la modifica di colonne / proprietà nel sistema sia una seccatura per te, potresti concentrarti sul miglioramento di quel processo, il che sarebbe vantaggioso per lo sviluppo dell'intero sistema.

Svantaggi della soluzione proposta, per come la vedo io:

Più complesso
Più difficile eseguire query ad-hoc come, quali utenti hanno un timeout maggiore di 500?
Non è estensibile come potresti pensare - come archivi una lista o qualcosa di più complesso come le relazioni? Certo, puoi risolverlo con la tua proposta ma arriverà con ancora più complessità.
Probabilmente meno performante

Come ultima riflessione, se questa è una grande idea, perché fermarsi con le impostazioni di configurazione utente e non usare questa soluzione per tutte le entità che sono memorizzate nel database?

risposta data 31.08.2018 - 10:09

fonte

-3

La tua soluzione sembra a posto.

Tuttavia, con il miglioramento del supporto di JSON nei sistemi di database (SQL e NoSQL), è possibile considerare l'archiviazione della configurazione utente in JSON. Questo è spesso un buon modo per archiviare dati la cui struttura non è fissa, ma si evolve in modo dinamico.

Per i valori predefiniti (e i tipi .NET, se ancora necessari), si avrebbe un record JSON aggiuntivo nel database.

Tuttavia, il principale svantaggio di una soluzione JSON è che il tuo codice si attaccherà a un sistema di database poiché il supporto JSON è molto diverso.

risposta data 31.08.2018 - 07:53

fonte

Leggi altre domande sui tag design c# design-patterns database-design configuration

Conversione di mappe dei processi aziendali in software Come scegliere la progettazione dello schema per un modello di dominio strutturato ad albero

score 2 · Accepted Answer

Questa soluzione mi sembra del tutto funzionale.

Un nitpick: trovo che quando devo memorizzare diversi tipi di cose in modo uniforme, e ci sia solo un numero piccolo, non espandibile di tipi che possono esistere, preferirei avere metodi separati readInt() , readString() ecc. e vivono con una piccola quantità di duplicazione piuttosto che specificare il parametro generico su ogni accesso. Almeno, vorrei scrivere involucri di "zucchero sintattico" in quello stile. Ma questa è davvero una questione su ciò che consideri più leggibile. Ovviamente, se ci sono un numero illimitato di tipi che devi supportare, la soluzione generica è la strada da percorrere.