Un'enumerazione in codice fornisce un modello di dominio più potente di una tabella statica?

Question

Un'enumerazione in codice fornisce un modello di dominio più potente di una tabella statica?

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

1

Un'enumerazione in codice fornisce un modello di dominio più strong di una tabella di database statica?

Ad esempio, supponiamo di avere un'entità Marble , con un attributo Color . L'attributo color ha un insieme finito di valori possibili, ad esempio rosso, verde, blu. Supponiamo che il team del database raccomandi di avere una tabella S_ValidColors statica, con l'effetto di:

-----------------------
| ColorId | ColorName |
-----------------------
|    0    |    Red    |
-----------------------
|    1    |   Green   |
-----------------------
|    2    |    Blue   |
-----------------------

Considerando che sto pensando più sulla falsariga di (questo è solo uno schizzo per il concetto generale):

public class Color {
    public static const Color Red = Color(0);
    public static const Color Green = Color(1);
    public static const Color Blue = Color(2);

    private Color(uint typeCode) {
        ...
    }
    ...
}

Oltre alla domanda su quale sia il migliore (che probabilmente dipende da un numero qualsiasi di altri fattori non rappresentati qui), è una domanda che tocchi quanto sia strong il modello di dominio? È un modo più anemico rispetto agli altri?

domain-model enum

posta Kazark 10.09.2013 - 23:10

fonte

3 risposte

2

Abbiamo avuto esattamente la stessa discussione qualche anno fa al mio vecchio lavoro. Alla fine, scegliamo la seconda opzione. Il ragionamento è:

Quando si modifica qualcosa in DB, si prevede che tali modifiche funzionino senza dover ridistribuire l'applicazione. Ma nel caso di questo tipo di enumerazioni, il codice potrebbe dipendere dal fatto che ci sono valori esatti per questa enumerazione. Diciamo che hai un interruttore che usa questa enumerazione e se viene fornito un valore non valido, genera un'eccezione. Avendo i valori codificati, puoi assicurarti che il tuo codice non causi errori attorno a tali enumerazioni. Anche quando un amministratore "intelligente" decide di aggiungere i propri valori.

Ovviamente, questo dipende. Se lavori solo con la lista di tutti i valori, allora questo non ha molto senso. Ma ha senso se lavori con specifici valori individuali nel tuo codice.

Inoltre, dover leggere quei valori dal DB può influire sulle prestazioni o creare codice complesso, anche se non sono realmente in evoluzione.

risposta data 11.09.2013 - 07:27

fonte

1

La creazione di un modello di database statico può fornire alcune difficoltà senza alcun vantaggio:

La lettura da un database sarà più lenta;
Se i valori dei colori cambiano, la distribuzione degli aggiornamenti sarà più difficile dal momento che non dovrai solo aggiornare l'origine, ma anche il database;
Come menzionato Euforic, sarai più soggetto a errori nel caso in cui alcuni degli oggetti nel DB manchino o siano modificati.

Quindi se non ci si aspetta che l'utente aggiunga i propri colori, non vedo alcun motivo per memorizzarli in un database.

risposta data 11.09.2013 - 08:56

fonte

Leggi altre domande sui tag domain-model enum

UML - Diagrammi del modello di classe di progettazione Che cosa sono le convenzioni di denominazione dei test TDD e di integrazione?

score 1 · Accepted Answer

Dipende interamente dall'uso dell'enum. Se stanno andando a cambiare spesso, nel DB è meglio, non si desidera ricompilare e ridistribuire una volta alla settimana perché Joe ha cambiato di nuovo il suo colore preferito. Se l'enumerazione è più fissa allora la codifica dura sarà migliore, è più facile ragionare e meno probabilità di essere infranto. Hai bisogno di accedervi dalle stored procedure? Potrebbe essere una buona idea averlo nel database in cui sia i proc memorizzati che il codice normale possono accedervi. Davvero non vuoi il mal di testa di mantenere due versioni differenti della stessa cosa. Che aspetto ha la logica che usa questa enumerazione? Ci sono situazioni in cui entrambe le opzioni sono più pratiche.

Per quanto riguarda la questione del modello di dominio anemico, non penso che si applichi. Finché il modello di dominio applica le regole ei processi del modello di dominio, il modello di dominio non è anemico. La memorizzazione dei valori nel DB li rende solo più dinamici e più facili da modificare (il che potrebbe essere una cosa negativa, date le giuste ipotesi).