Nullable enumeration values vs. "NoValue" o "Undefined", ecc.

3

Scrivo spesso codice che traduce le entità nel database in oggetti del dominio. Queste entità hanno spesso campi che sono vincolati e tradotti in enumerazioni negli oggetti del dominio. In alcuni casi, tuttavia, i campi possono essere nulli.

Ad esempio, immagina di avere un'entità PrintJob con un campo Status che può essere New , Submitted o Completed e un campo Result che può essere Succeeded , FailedNoPaper o FailedNoToner ma può anche essere NULL se Status non è Completed .

Da un lato, mi piace avere una mappatura uno-a-uno dei valori del campo entità ai valori enum dell'oggetto dominio, ma d'altra parte, in qualche modo sembra "migliore" avere sempre valori per le proprietà con tipi di enumerazione.

La mia domanda è: è meglio rappresentare il valore del campo Result nel mio oggetto dominio come valore nullable (ad esempio MyStatus? in C # o VB.NET) che non ha alcun valore quando il campo entità corrispondente è NULL , o dovrei creare un valore enum speciale insieme agli altri, ad es NoValue o Undefined ?

    
posta rory.ap 06.01.2015 - 15:29
fonte

3 risposte

5

Se un valore di campo è uno di un elenco di valori predefiniti, il tuo dominio avrà un valore reale che puoi corrispondere a NULL. Tutto quello che devi fare è cercarlo. Se lo stato non è completato, il risultato potrebbe essere "NotFinished", "Unavailable", "DoesNotExist" o "Unknown".

Pensa a questo in modo non codice. Se si stampa qualcosa e si chiede a un collega di portare la pila di fogli dalla stampante, come ti farebbe sapere che non c'è nessuna stampa sulla stampante? Potrebbe dire che non è ancora finito, non era ancora disponibile, non c'era nulla sulla stampante ...

Per quanto riguarda le enumerazioni, non sono un grande fan delle enumerazioni nullable. Aggiungi un singolo campo predefinito come 'Sconosciuto' e non devi MAI MAI preoccuparti che sia NULL. Altrimenti, spenderete delle risme di codice nella vostra applicazione per controllare prima il NULL prima di fare qualcosa di ragionevole ... Gli enum, come i booleani, dovrebbero evitare di essere NULL.

    
risposta data 06.01.2015 - 16:24
fonte
1

Considerando questo come un problema di macchina dello stato, in cui ogni stato era rappresentato da un enum, sarebbe ragionevole fornire un enum per tutti gli stati, incluso lo stato "non ancora". Sarei tentato di nominarlo qualcosa di significativo, però, come "PROCESSING" piuttosto che come sinonimo di "NULL".

Mettendo da parte i problemi programmatici con NULL, rappresentare lo stato come NULL sarebbe un modo valido per dire "nessuno stato". Ma mettere il secondo valore in uno stato iniziale noto è più definitivo.

    
risposta data 06.01.2015 - 16:36
fonte
0

Confronta la tua situazione con la stringa vuota / stringa nulla:

Una stringa vuota (in C: '\ 0') significa che la stringa non ha alcun valore, mentre la stringa nulla significa che non ha un valore.

Poiché il valore del risultato non è noto fino al termine del lavoro, il valore nullo sembra corretto. Naturalmente puoi usare un valore enum per indicare "non noto per essere conosciuto". Significa anche che non puoi interrogare il valore del risultato finché non hai controllato che lo stato sia "completato".

    
risposta data 10.01.2015 - 10:02
fonte

Leggi altre domande sui tag