Modèles de conception de code d'état

Question

Supposons que vous ayez un objet "post" dans un scénario de blog classique. Un article de blog peut avoir différents statuts tels que «brouillon», «publié», «approuvé», et cetera. Quelles sont les meilleures façons de gérer cela, en particulier en ce qui concerne le stockage de ces données dans la base de données d'une manière significative et de manière significative dans le code.

En général, j'ai vu ces stocké comme un int associé à une ligne dans la base de données (de la table « postes » dans cet exemple). Parfois, il y a une table de recherche dans la base de données pour expliquer ces états (c'est-à-dire la table d'état avec id => 1 name => draft, etc.). Normalement, je les traduis en une énumération dans la couche d'accès aux données pour avoir une représentation de code plus significative et pour éviter d'avoir des «nombres magiques».

Cependant, cette solution a une mise à jour de développeur deux endroits différents (base de données et le code) pour ajouter ou modifier un type d'état.

Quelle est la meilleure façon de faire cela? Cela semble être un type de problème que j'ai rencontré fréquemment, mais je n'ai jamais vu un bon moyen de le gérer.

Answer 1

J'aime mettre un status_id et la création d'une table de consultation avec les statuts en elle et un enum corrresponding comme vous le suggérez. Si mes statuts sont essentiellement immuables (par exemple, état d'un article de blog, état d'un ordre, etc.), je vais créer un test unitaire qui déterminera si le nombre d'énumérations que j'utilise correspond aux données de la table de correspondance. donc si quelqu'un devait ajouter un statut à la base de données à l'avenir, il échouerait au test, disant au développeur d'ajouter à l'énumération.

Answer 2

IMO, ils ne doivent être en un seul endroit, si vous mappez brouillon à un enum DRAFT dans le code qui signifie probablement que vous ajoutez comportement à brouiller dans le code, comme si le projet est modifiable par exemple et de prendre des décisions sur ça . Mon approche ici serait de déplacer le comportement vers la base de données et d'ajouter une colonne à DB pour ce comportement (comme la colonne booléenne pour dire si elle est éditable) et le mapper à la classe d'état au lieu d'une énumération. Donc, si un nouveau statut est introduit, il peut simplement être ajouté à db avec le comportement correspondant.

Answer 3

Je suis d'accord avec la réponse de John Rasch, mais vous êtes peut-être intéressé par un article sur Codeproject qui parle de la génération dynamique d'enums