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

Question

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

例如，我有许多类型的用户，并且在用于创建用户的表单中，有一个下拉列表来指定哪种类型的用户。

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

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

你能告诉我这方面的好心理吗？

由于

Answer 1

在您的情况下 - 数据库将是最好的做法，特别是如果它的动态数据。枚举是针对很少更改的那些值，可能偶尔会更改一次，但不会频繁更改。您可能会定期在数据库中输入新条目，尤其是级联下拉列表等内容。

数据库肯定是你的方式。枚举存在于那些只是一个标准并且很少改变的时候，例如：

先生。 小姐。 太太。 女士。 博士

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

Answer 2

我强烈反对使用枚举来实现这种功能，基本上有两个原因：

• 枚举值没有行为，因此妥协良好的OOP。一个好的类具有数据+行为，因此枚举成员不足以专门表示它们的命名概念。关于这个域对象的逻辑生活在除了其名称的实体之外的其他地方，我不喜欢。
• 枚举是为了传达正常性，所以DaysOfWeek是一个很好的用法（除了一周中的哪一天是'第一'因文化而异，但是'挑剔'），因为枚举表示订购的成员。在您的情况下，说某个特定值是“第一个”用户类型，第二个值是第二个，依此类推是否有意义？可能不会。

Answer 3

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

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

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

至于本地化，您的选择完全相同。只需使用＆＃34; UserType-XXX＆＃34;等资源键，其中XXX是该类型的数据库ID。如果需要，还可以将本地化值存储在数据库中。只要做最适合您应用的事情。