Utilisation de Enum pour "l'état" d'un objet de couche de données en C #

Question

J'ai un objet de données (disons qu'il s'appelle 'Entrée') qui a un ensemble d'états potentiels qui ressemblent à ceci:

1 - Created
2 - File added
3 - Approved
4 - Invalid

Ceci est représenté dans la base de données avec une table 'Status' avec une clé primaire avec numérotation automatique, puis un champ 'StatusId' dans la table principale, avec les relations appropriées configurées.

Dans ma couche de données (personnalisée), j'ai l'objet "Entrée" et, à l'heure actuelle, je déclare également un Enum avec les états énumérés ci-dessus. Enfin, je déclare une instance privée de cet Enum avec la propriété publique appropriée.

Dans ma méthode 'Commit ()', je convertis l'instance de Enum en un entier et le passe à une procédure stockée Update.

Dans ma méthode statique 'GetEntry ()', je vais évidemment recevoir un entier renvoyé de la base de données. J'utilise ensuite la méthode 'Enum.Parse ()' pour extraire un objet qui est une instance de my Enum qui correspond à l'entier de statut renvoyé. Je jette ceci dans le type de mon Enum et l’assigne à la variable privée locale.

Ma question est assez simple: cette approche est-elle appropriée? Sinon, quelle solution de rechange, hormis le simple stockage de la valeur entière brute (pour laquelle je ne suis pas nécessairement opposé), est préférable.

La raison pour laquelle je vous pose cette question est que tout cela me semble incroyablement compliqué, avec tout le casting et le maintien de deux listes du même ensemble de valeurs. Je reconnais que l'avantage réside dans une meilleure expérience pour le consommateur de l'objet de données, mais malgré tout ...

Merci!

Answer 1

Nous avons quelque chose de familier dans l'un de nos projets. Nous avons une table contenant des types d'éléments. Ces types ont un identifiant, dans le code nous avons une enum avec les mêmes identifiants. Le problème est que, dans la base de données, nous n'utilisons pas la numérotation automatique (identité), nous avons donc un contrôle total sur l'identifiant. Et lors de la sauvegarde de notre objet, nous prenons simplement l'identifiant de l'énum pour sauver l'objet. Je pensais aussi que cette approche était désordonnée, mais ce n’est pas si grave après tout.

Answer 2

Cette méthode me semble correcte.

Par le passé, j’ai fait la même chose, mais j’avais également une table contenant une ligne pour chaque membre de l’énum. Cette table était alors la clé étrangère de toute table utilisant la valeur enum, juste pour que quelqu'un lise la base de données. pourrait comprendre ce que chaque statut était sans avoir à voir l'énumération réelle.

par exemple si j'avais un enum comme

enum status
{
    Active,
    Deleted,
    Inactive
}

J'aurais une table appelée status qui aurait les enregistrements suivants

ID & nbsp; & nbsp; Nom
0 & nbsp; & nbsp; & nbsp; Actif
1 & nbsp; & nbsp; & nbsp; Supprimé
2 & nbsp; & nbsp; & nbsp; Inactif

Cette table serait alors la clé étrangère de toutes les tables utilisant cette énumération.

Answer 3

Ouais c'est bien!

PLEASE définit toujours explicitement les valeurs comme ceci. De cette façon, si quelqu'un ajoute quelque chose, il réalisera que les valeurs sont importantes et ne devraient pas être dérangées.

enum status
{
    Active = 1,
    Deleted = 2,
    Inactive = 3
}

Si vous transmettez la valeur via WCF, je vous recommande d'ajouter

.

  NULL = 0

Sinon, si vous essayez de sérialiser un 0 provenant de la base de données, vous obtiendrez une horrible erreur et il vous faudra toute une vie pour le déboguer.

Answer 4

la table de consultation de la base de données est nécessaire; l'énumération programmatique est pratique pour éviter d'avoir des "nombres magiques" dans le code

si votre code n'a pas besoin de manipuler le statut, l'énumération est inutile.

Answer 5

Je fais cette approche avec Enums tout le temps. S'il s'agit d'un élément simple, tel que le statut, qui ne devrait pas changer, je préfère l'enum. L'analyse et la diffusion sont une opération à très faible impact.

Je fais cela avec succès avec Linq to Sql depuis quelque temps maintenant sans aucun problème. Linq convertira automatiquement Enum en int et en arrière automatiquement.

Le code ne se limite pas à la vitesse, mais à la lisibilité. Les énumérations rendent le code lisible.

Pour répondre directement à votre question, il s'agit d'une approche très valable.

Answer 6

Si votre code nécessite la définition du paramètre " Statut " connu, valeurs (que vous avez définies dans votre enum), il est donc probablement également obligatoire que celles-ci " Status " des valeurs existent dans la base de données. Dans la mesure où elles doivent exister, vous devez également avoir le contrôle sur l’ID de statut attribué à chacune de ces valeurs.

Supprimez l'identité et définissez explicitement les identifiants de valeur de recherche.