En utilisant Enum pour en C#

Question

je de l'objet de la couche de données « statut » un objet de données (disons qu'il est appelé « entrée ») qui a un ensemble d'états potentiels qui ressemblent à ceci:

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

Cette est représenté dans la base de données avec une table 'Status' avec une clé primaire autonumber, 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, actuellement, je déclare également un Enum avec les états listé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 transtype l'instance de Enum en entier et la passe à une procédure stockée Update.

Dans ma méthode statique 'GetEntry()', je vais évidemment avoir 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 mon Enum qui correspond à l'entier retourné. Je jette ceci au type de mon Enum et l'assigne à la variable privée locale.

Ma question est assez simple - est-ce une approche appropriée, et sinon quelle alternative, autre que de simplement stocker la valeur entière brute (que je ne suis pas nécessairement opposée à), c'est mieux.

Ma raison de demander est que tout cela me semble incroyablement salissant, que de tout le casting et le maintien de deux listes du même ensemble de valeurs. J'accepte l'avantage réside dans une meilleure expérience pour le consommateur de l'objet de données, mais même si ...

Merci!

Answer 1

Nous avons quelque chose de familier dans l'un de nos projets. Nous avons une table containtant les types d'articles. Ces types ont un identifiant, dans le code nous avons une énumération avec le même identifiant. La chose est, dans la base de données, nous n'utilisons pas autonumber (identité) donc nous avons le contrôle total de l'ID. Et lors de la sauvegarde de notre objet, nous prenons simplement l'identifiant de l'énumération pour enregistrer l'objet. J'ai également pensé que cette approche était désordonnée mais ce n'est pas si mauvais après tout.

Answer 2

Cette méthode me semble bien. Dans le passé, j'ai fait la même chose mais j'avais aussi une table qui contenait une ligne pour chaque membre de l'énumération. Cette table était alors la clé étrangère pour toute table qui utilisait la valeur enum, juste pour que quelqu'un lise le 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 
} 

Je voudrais avoir une table état appelé qui aurait les documents suivants

ID     Nom
    active
    Supprimé
    Inactif

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

Answer 3

la table de recherche de base de données est nécessaire; l'ENUM programmatique est pratique pour éviter d'avoir « nombres magiques » dans le code

si votre code n'a pas besoin de manipuler l'état, cependant, le ENUM est inutile

Answer 4

Je fais cette approche avec énumérations tout le temps .Si c'est un élément simple comme le statut qui ne devrait pas changer, je préfère l'Enum. L'analyse et la coulée est une opération à très faible impact.

Je l'ai fait avec succès avec Linq à Sql depuis un certain temps maintenant sans problèmes. Linq convertira réellement d'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 application très valable.

Answer 5

Si votre code requiert la définition de valeurs «Status» connues (que vous avez définies dans votre énumération), il est probablement également nécessaire que ces valeurs «Status» existent dans la base de données. Comme ils doivent exister, vous devez également avoir le contrôle du Status_ID affecté à chacune de ces valeurs. Supprimez l'identité et définissez explicitement les ID de valeur de recherche.

Answer 6

Yup c'est bien!

VEUILLEZ toujours définir explicitement les valeurs comme ceci. De cette façon, si quelqu'un va ajouter quelque chose, il se rendra compte que les valeurs sont importantes et ne doivent pas être mélangées.

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

Si vous passez la valeur autour de 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 erreur horrible et il Je vais vous prendre pour toujours pour déboguer.