我时不时会思考这个问题，所以我想我会问你们。
假设我有一个如下所示的数据库表：
Table: Visibility
Id Value
-- -----
0 Visible
1 Invisible
2 Collapsed
这只是一个用于确保参照完整性的表。它基本上是一个存储在数据库中的枚举，用于确保出现在其他表中的任何 Visiblity 值始终有效。
在我的前端，我有一些选择。
Dictionary<string, int>或 aDictionary<int, string>中。我可以手动编写一个枚举，并在表发生更改的罕见事件中手动编辑值。例如，
public enum Visiblity
{
Visible,
Invisible,
Collapsed
}
你会建议哪一个，为什么？
谢谢。
对于像这样相当琐碎的事情，我通常会使用枚举。我可以认同你，因为我觉得这并不完全正确……但在我看来，这是两害相权取其轻。
对此有一些额外的理由：如果由于某种原因要添加第四个值，那么您的代码无论如何都需要更新才能能够处理它。当您使用它时，更新枚举也很容易。
如果您需要向表中添加新值，这是否需要在您的应用程序中更改编码以支持该新值？如果是这样，请将其设为enum.
根据您的数据库，您可以将可见性字段设为枚举类型。这样，数据必须是您在创建表时指定的选项之一。
如果您必须根据该表中的值在应用程序中执行分支代码，您可能希望将该表表示为一个枚举。如果没有，让它只是另一个类就可以了。
这就是代码生成派上用场的地方 - 如果您使用可以将表生成为枚举的东西，您不必考虑保持表和枚举同步 - 只需将行添加到表中，然后下一个当您生成业务层时，枚举会自行更新。
如果您有任何基于枚举的业务逻辑，您的主要选择是手动同步。如果这些行也是另一个表的外键（假设您有一个状态查找表），您应该将 ID 类型设置为具有唯一索引而不是 Identity 的常规 int，以便您可以轻松维护 ID/值对如果您在不同环境中拥有数据库，则相同。
与 Scott Ivey 的回答相反，我更喜欢（但很少使用）我只维护枚举的方法，并且在应用程序启动时（或者可能在构建事件中），使用反射来确保表值与我的枚举值匹配。这不需要任何代码生成，但容易受到引用约束违规的后期检测。