Quali sono gli svantaggi di mappare identificatori integrali su enum?

Ho pensato di creare tipi personalizzati per identificatori come questo:

public enum CustomerId : int { /* intentionally empty */ }
public enum OrderId : int { }
public enum ProductId : int { }

La mia motivazione principale per questo è prevenire il tipo di bug in cui si passa accidentalmente un orderItemId a una funzione che si aspettava un orderItemDetailId.

Sembra che gli enum funzionino perfettamente con tutto ciò che vorrei usare in una tipica applicazione Web .NET:

• Il routing MVC funziona correttamente
• La serializzazione JSON funziona correttamente
• Ogni ORM a cui riesco a pensare funziona bene

Quindi ora mi chiedo "perché non dovrei farlo?" Questi sono gli unici inconvenienti che mi vengono in mente:

• Potrebbe confondere altri sviluppatori
• Introduce incoerenze nel sistema in caso di identificatori non integrali.
• Potrebbe richiedere un casting extra, come (CustomerId)42. Ma non penso che questo sarà un problema, dal momento che il routing ORM e MVC in genere ti consegnerà direttamente i valori del tipo enum.

Quindi la mia domanda è: cosa mi sto perdendo? Questa è probabilmente una cattiva idea, ma perché?

È un'ottima idea creare un tipo per ogni tipo di identificatore, principalmente per i motivi indicati. Non lo farei implementando il tipo come enum perché renderlo una corretta struttura o classe ti dà più opzioni:

• È possibile aggiungere la conversione implicita a int. Quando ci pensi, è l'altra direzione, int -> CustomerId, quella problematica che merita una conferma esplicita da parte del consumatore.
• È possibile aggiungere regole aziendali che specificano quali identificatori sono accettabili e quali no. Non si tratta solo di verificare se l'int è positivo: a volte, l'elenco di tutti gli ID possibili viene conservato nel database, ma cambia solo durante la distribuzione. Quindi puoi facilmente verificare che l'ID dato esista rispetto al risultato memorizzato nella cache della query corretta. In questo modo, puoi garantire che la tua applicazione fallirà rapidamente in presenza di dati non validi.
• I metodi sull'identificatore possono aiutarti a eseguire costosi controlli di esistenza DB o ottenere l'oggetto entità / dominio corrispondente.

Puoi leggere su come implementarlo nell'articolo C # funzionale: ossessione primitiva .

È un trucco intelligente, ma è comunque un trucco che abusa di una funzionalità per qualcosa che non è lo scopo previsto. Gli hack hanno un costo in termini di manutenibilità, quindi non è sufficiente non trovare altri inconvenienti, ma devono anche avere vantaggi significativi rispetto al modo più idiomatico per risolvere lo stesso problema.

Il modo idiomatico sarebbe quello di creare un tipo di wrapper o una struttura con un singolo campo. Questo ti darà la stessa sicurezza in un modo più esplicito e idiomatico. Mentre la tua proposta è certamente intelligente, non vedo alcun vantaggio significativo nell'uso dei tipi di wrapper.

Dal mio punto di vista, l'idea è buona. L'intenzione di fornire tipi diversi a classi di identificatori non correlate, e di esprimere in altro modo la semantica tramite tipi e lasciare che il compilatore lo controlli, è buona.

Non so come funziona in .NET dal punto di vista delle prestazioni, ad esempio i valori enum sono necessariamente inscatolati. Il codice OTOH che funziona con un database è comunque probabilmente associato a I / O e gli identificatori inscatolati non avranno alcun collo di bottiglia.

In un mondo perfetto, gli identificatori sarebbero immutabili e comparabili solo per l'uguaglianza; i byte effettivi sarebbero un dettaglio di implementazione. Gli identificatori non correlati avrebbero tipi incompatibili, quindi non potresti usarne uno per errore. La tua soluzione si adatta praticamente al conto.

Non puoi farlo, gli enum devono essere predefiniti. Quindi, a meno che tu non sia disposto a pre-definire l'intero spettro di possibili valori degli ID cliente, il tuo tipo sarà inutile.

Se lanci, sfideresti il ​​tuo obiettivo principale di impedire l'assegnazione accidentale di un ID di tipo A a un ID di tipo B. Quindi gli enum non sono utili al tuo scopo.

Ciò solleva tuttavia la domanda se sarebbe utile creare i tuoi tipi per ID cliente, ID ordine e ID prodotto scendendo da Int32 (o Guid). Mi viene in mente un motivo per cui questo sarebbe sbagliato.

Lo scopo di un ID è l'identificazione. I tipi integrali sono già perfetti per questo, non ottengono più l'identificazione discendendo da loro. Non è richiesta né desiderata la specializzazione, il tuo mondo non sarà rappresentato meglio avendo tipi diversi di identificatori. Quindi dal punto di vista OO sarebbe male.

Con il tuo suggerimento vuoi qualcosa di più della sicurezza del tipo, vuoi la sicurezza del valore e questo va oltre il dominio della modellazione, questo è un problema operativo.