最佳实践：使用枚举或不存储下拉值答案

【问题标题】：Best practice : use enum or not to store dropdown values最佳实践：使用枚举或不存储下拉值
【发布时间】：2013-11-25 12:48:13
【问题描述】：

我正在开发一个应用程序，我经常问自己同样的问题。

例如，我有多种类型的用户，在用于创建用户的表单中，有一个下拉菜单可以指定用户的类型。

填充此下拉列表的最佳方法是将值存储在数据库的表中？如果我这样做，当我开发时我想测试用户类型并且我只有一个 int。但我认为使用枚举进行测试是一种更好的做法。所以我创建了枚举，但我觉得这是一种不好的做法，因为我必须保持数据库和枚举同步。

另一个问题是关于本地化的。如果我将值放入数据库中，我将无法使用资源文件。

你能告诉我这方面的好做法吗？

谢谢

【问题讨论】：

【解决方案1】：

在您的情况下 - 数据库将是这里的最佳实践，特别是如果它的动态数据。 enum 用于那些很少改变的值，可能偶尔改变一次，但不是经常改变。您可能会定期在数据库中输入新条目，尤其是对于级联下拉列表等内容。

数据库当然是适合您情况的方法。枚举是在它们只是一个固定标准并且很少改变的时候出现的，例如：

先生。错过。太太。小姐。博士

你会在枚举中拥有这些，因为它们永远不会真正改变。另一方面，如果要更改或重命名商店部门，则数据库将是存储此类条目的地方。

【讨论】：

我同意你的例子，动态数据不问我问题。例如，我问自己“先生。女士。太太……”。那么在这种情况下，您是否开发了一个控件来为每个枚举值呈现一个标签？还是您在页面中硬编码？
这取决于你。我通常在枚举上使用自定义属性，因此我使用反射给我一个包含枚举描述的字符串列表，然后在页面上呈现它。您可以使用下拉列表创建用户控件，然后给它一个键值对列表，其中键是 int，值是要显示的描述。 int 就像某种“ID”。
我也使用 description 属性，但我必须本地化这个字符串。此外，我认为将文本存储在代码中是一种不好的做法。我想在描述属性中使用resourceKey，你怎么看？
是的，对不起 - 这就是我的意思。使用某种资源字典。
这也是我的结论，但我不确定这种做法。谢谢

【解决方案2】：

我强烈反对将枚举用于这种功能，主要有两个原因：

枚举值没有任何行为，因此需要妥协良好的 OOP。一个好的类具有数据+行为，因此枚举成员没有足够的专业性来表示它们命名的概念。关于这个领域对象的逻辑存在于其他地方，而不是以其名字命名的实体，我不喜欢。
枚举是为了传达顺序，所以DaysOfWeek 是一个很好的用法（除了一周中的哪一天是“第一”，这取决于文化，但那是“吹毛求疵”），因为枚举表示 顺序的成员。在您的情况下，说特定值是“第一个”用户类型，第二个值是第二个，等等是否有意义？可能不会。

【讨论】：

例如，我为发票开发了一个业务层。我的 Invoice 对象上有一个发票类型。您的回答意味着使用 enum 输入发票不好，因为它不会影响发票的行为？但是，这种类型允许我修改行为。

【解决方案3】：

我的第一个问题是——你真的在数据库中的任何地方使用用户类型吗？如果答案是否定的，一切都会变得更容易，因为您可以简单地使用枚举并完成它。

否则，您可能还应该有一个用户类型表，以便正确使用外键。

就我个人而言，我对这些使用手动 ID - 自动生成的密钥会使您尝试同步代码和数据库的尝试变得一团糟。理想情况下，如果您的 ORM 允许，您可以让代码-数据库自动同步 - 通过代码生成或通过自动数据库数据更新。但是，如果您不能，手动编码枚举（或某种伪枚举）在代码中应该会更好。

至于本地化，您的选择完全一样。只需使用“UserType-XXX”之类的资源键，其中 XXX 是该类型的数据库 ID。如果需要，您还可以将本地化值存储在数据库中。只做最适合您的应用程序的事情。

【讨论】：