你把字典数据放在哪里？

Question

假设我的应用程序中有一组国家/地区。我希望这些数据能够改变，但不是经常发生。换句话说，我不会将此集视为操作数据（例如，我不会为Country提供CRUD操作）。

那说我必须将这些数据存储在某个地方。我认为有两种方法可以做到这一点：

• 数据库驱动。创建并填充Country表。提供某种DAO来访问它（findById（）？）。这样，客户端代码必须知道国家/地区的ID（也可以是名称或ISO代码）。在申请方面，我将有一个国家级。

• 应用程序驱动。创建一个枚举，我可以列出我系统已知的所有国家/地区。它也将存储在DB中，但区别在于现在客户端代码不必具有查找方法（findById，findByName等）和硬编码ID，名称或ISO代码。它将直接引用特定国家。

我倾向于第二种解决方案有几个原因。你是怎么做到的？

这个'词典数据'是否正确？

附录：这里的一个主要问题是，如果我有一个像 findByName（“捷克斯洛伐克”）的查找方法，那么在1992年之后，这将不会返回任何内容。我不知道客户端代码将如何对它作出反应（毕竟sorta期望总是让国家回来，因为，好吧，它是一个字典数据）。如果我有像 findById（ID_CZ）这样的东西会更糟。找到所有这些依赖关系真的很难。

如果我要从我的枚举中删除Country.Czechoslovakia，我将强迫自己照顾对捷克斯洛伐克的任何依赖。

Answer 1

在我工作的一些应用程序中，数据库中有一个包含所有此类数据的“Enum”表。它只包含两列：EnumName和Value，并将填充如下：

• “国家”，“德国”
• “国家”，“英国”
• “国家”，“美国”
• “水果”，“Apple”
• “水果”，“香蕉”
• “水果”，“橙色”

然后在应用程序执行开始时读入并缓存。优点是我们没有为每个不同的枚举类型使用数十个数据库表;如果我们需要更改数据，我们不必重新编译任何内容。

这可以很容易地扩展到包括额外的列，例如指定默认排序顺序或替代ID。

Answer 2

如果它不会经常更改并且你可以负担得起应用程序来应用更新，我会将它放在Java枚举中并为findById()编写我自己的方法，findByName()等等。

优点：

• 快速 - 无法访问不变数据（或缓存要求）;
• 简单;
• 使用重构工具玩得很好。

缺点：

• 需要关闭应用程序以进行更新。

如果将数据放在自己的jar文件中，更新就像更新jar并重新启动应用程序一样简单。

硬编码问题可以通过消费者存储枚举本身的值，或者通过引用国家不太可能改变的ISO代码来消失......

如果您担心将此枚举与数据库“同步”，请编写一个集成测试，准确检查并定期运行（例如：在CI计算机上）。

Answer 3

就个人而言，我总是选择数据库方法，主要是因为我已经将其他信息存储在数据库中，因此编写另一个DAO很容易。

但另一种方法可能是将它存储在jar中的属性文件中？我从来没有在Java中这样做，但它似乎在iPhone开发中很常见（我正在学习的东西）。

Answer 4

我的jar中可能有一个文本文件。我会在启动时（或首次使用时将其加载到内存中）。此时：

• 很容易改变（即使是没有编程知识的人）
• 即使没有完全重新部署也很容易更新 - 将只是文本文件放在类路径的某个地方
• 无需数据库访问

编辑：好的，如果你需要从代码中引用特定的国家/地区数据，那么：

• 使用枚举方法，始终意味着重新部署
• 使用上述方法，但保留国家ID的枚举，然后进行单元测试以确保每个ID都映射到文本文件中。这意味着您可以在不重新部署的情况下更改其余数据，并且非技术人员仍然可以更新数据，而无需在任何地方看到可怕的代码。

最终，这是一个平衡利弊的案例 - 如果上述优势与你无关（例如总有一个编码器，并且部署不是问题），那么枚举就有意义。< / p>

Answer 5

这对你没有帮助，但这取决于......

- 你打算对这些国家做什么？

您是否将它们存储在数据库中的其他表格中/如果您添加新国家/现有数据将会发生什么/其他应用程序是否会访问这些数据？

- 你打算用几种语言翻译contry名字吗？

- 您的应用程序的业务逻辑是否取决于所选择的国家/地区？ - 你需要国家课吗？

等...

如果没有更多信息，我会从一个包含少数几个国家的Enum开始，并根据我的需要进行重构......

Answer 6

使用数据库表的一个优点是您可以设置foreign key约束。这样您的referential integrity将始终保持不变。无需像DanVinton suggested那样为枚举运行集成测试，它永远不会失去同步。

我也不会尝试将一般的枚举表作为saw-lau suggested，主要是因为你失去了干净的外键约束，这是将它们放在数据库中的主要优点（可能很好地将它们粘在文本文件中）。数据库擅长处理大量表。如果要以某种方式区分它们，请使用“ENUM_”作为表名的前缀。

应用程序始终可以将它们作为启动时间或重新加载事件触发时加载到Map中。

编辑：来自评论，“当然我会在我的数据库中使用外键约束。但是可以使用或不使用应用程序端的枚举来完成

”

啊，我在阅读你问题中的第二个要点时错过了这一点。但是我仍然说最好将它们加载到Map中，主要基于DRY。否则，当需要维护它的人来添加一个新的国家时，他们肯定会在一个地方而不是另一个地方进行更新，并且在他们发现他们需要在两个不同的地方更新它之前会摸不着头脑。案例premature optimisation。性能优势很小，代价是可维护性较低的代码，恕我直言。

Answer 7

我开始做最简单的事 - 一个枚举。当谈到国家/地区的变化几乎与我的代码一样频繁时，我会将表格外部化，以便可以在不重建的情况下进行更新。但请注意，当您将其设置为外部时，您可以添加一整套UI，测试和文档蠕虫。