Quand les énumérations s'interrompent-elles ?


Pour prendre en charge une nouvelle fonctionnalité dans un système existant, j'envisageais simplement d'implémenter une forme de discriminateur dans une table d'entités dans mon schéma de base de données.

En voulant commencer par faire la moindre chose qui fonctionnera, j'ai tout d'abord choisi une colonne entière et une énumération C# au niveau de la couche d'entité commerciale pour des raisons de lisibilité. Cela fournirait le polymorphisme du pauvre qui pourrait éventuellement se transformer en un véritable polymorphisme et peut-être vers un modèle de stratégie.

J'ai décidé de consulter la blogosphère car je n'ai jamais été tout à fait à l'aise avec l'utilisation des énumérations - je me suis demandé si je devais sauter l'énumération et aller directement à une structure ou à une classe ? :

Tout d'abord, j'ai trouvé une affirmation selon laquelle 'Enums are Evil', mais j'ai senti que c'était une généralisation excessive qui ne concerne pas directement mon cas d'utilisation.

Si je choisis une énumération, il y a une bonne discussion sur la façon dont je peux étendre mon kilométrage en ajoutant un supplément métadonnées à mon enum.

Ensuite, je suis tombé sur les discussions de Jimmy Bogard sur Enumeration Classes et discuté plus en détail dans 'Stratégies et discriminateurs dans NHibernate'

Dois-je sauter les énumérations et passer directement aux classes d'énumération ? Ou quelqu'un a-t-il d'autres suggestions sur la façon d'ajouter un discriminateur d'entité simple à mon modèle de domaine.

Mise à jour:

J'ajouterais également que NHibernate et LINQ to SQL (et probablement toutes les autres méthodes d'accès aux données liées à ORM) rendent l'utilisation des énumérations très attrayante car elles vous permet de mapper une colonne discriminante de manière transparente dans le mappage.

Serait-il aussi simple de mapper une classe d'énumération ?

Questions connexes:


Avertissement:

Malgré mon utilisation négligente du terme entité (avec un 'e' minuscule), je ne prétends pas discuter de DDD ici...

6
rohancragg 30 nov. 2009 à 14:24
Les lecteurs voudront peut-être noter que si vous décidez d'utiliser une énumération, il y a une discussion intéressante sur la question de savoir si/comment conserver les valeurs dans la base de données ici stackoverflow.com/questions/746812/…
 – 
rohancragg
30 nov. 2009 à 17:34

2 réponses

Meilleure réponse

Ces classes d'énumération ont l'air soignées, j'ai souvent regardé jalousement les énumérations de Java.

Je pense que les règles habituelles s'appliquent : faites la chose la plus simple qui puisse fonctionner. Si vous vous retrouvez avec plus d'un switch sur l'énumération, alors c'est une odeur et il est temps de considérer le modèle que vous avez trouvé.

Sinon, pourquoi vous encombrer de quelque chose dont vous n'avez pas besoin ?

2
Jeremy McGee 30 nov. 2009 à 14:29

Aujourd'hui, les énumérations sont mauvaises, demain la POO pourrait être mauvaise et AOP ira bien.

Utilisez simplement le bon outil pour le travail. N'oubliez pas, Keep It Simple...

Si l'énumération sert uniquement à indiquer le type d'un objet, ne vous embêtez pas, utilisez-la.

S'il contient une logique métier, il s'agit probablement d'une autre classe.

5
Gabriel GM 11 avril 2018 à 18:28
Le problème avec le démarrage simple est que si j'utilise un Enum, ma "clé étrangère" est un entier. Si je refactorisais plus tard le discriminateur comme étant une entité complète de première classe (bien que juste une table de recherche), je souhaiterais peut-être que la clé étrangère ait été un GUID (qui se trouve être la « norme » que nous utilisons pour les clés dans notre schéma.
 – 
rohancragg
30 nov. 2009 à 14:37
Ensuite, mappez Enum en tant que guide. Pensez juste si vous en avez vraiment besoin MAINTENANT. Sinon, restez simple.
 – 
Dmytrii Nagirniak
30 nov. 2009 à 15:56
OK bien. Mais si, à ce stade, j'ai un héritage de données, j'ai une refactorisation de base de données assez non triviale à faire.
 – 
rohancragg
30 nov. 2009 à 16:08
Et si vous ne voulez pas ? Vous conserverez une solution plus complexe pendant la durée de vie de l'application. Alors introduisez de la complexité si vous SAVEZ qu'elle est nécessaire.
 – 
Dmytrii Nagirniak
1 déc. 2009 à 01:20
Ironiquement, j'ai décidé de m'écarter de la « norme » car il s'agit d'une recherche et non d'une entité, il semblait donc plus logique d'avoir un PK entier au lieu d'un GUID (ce que les DBA détestent de toute façon). Je sens une toute nouvelle question arriver concernant la modélisation des recherches par rapport aux entités... :-)
 – 
rohancragg
2 déc. 2009 à 11:55