存储 Java UI 应用程序配置/设置的最佳实践
我正在研究存储应用程序配置数据同时支持层次结构和动态加载的最佳方法是什么。
数据示例：
- 每列的位置（我们会显示很多表格）
- 如何可视化每列或单元格中的数据（例如，某些列可能有不同的方式来显示相同的指标）
- 数据格式（日期或数字）
层次结构意味着：
我有一个州有多个地区，因此会有默认配置，但州可以覆盖部分（或全部）默认配置，地区可以覆盖状态配置的一部分。
动态加载意味着：
能够动态加载和应用新配置，无需重新启动服务器，甚至不需要用户登录。
配置存储格式（可以是文件或数据库）：
- XML – 这就是我过去使用的
- JSON – 所以我可以从配置文件或数据库读取 JSON 并将其作为应用程序中的对象内存
- 键值对
- 其他格式？
您对这个主题有什么想法/知识？
谢谢你！
I'm researching what is the best way to store application configuration data while supporting hierarchy and dynamic loading.
Data examples:
- Where to locate each column (we would display a lot of tables)
- How to visualize data in each column or cell (for example some column may have different ways to show the same metric)
- Data format (date or numbers)
Hierarchy means:
I have a state that has several districts, so there will be default configuration, but a state can override parts (or all) of the default configuration and a district can override parts of the state configuration.
Dynamic loading means:
Ability to dynamically load and apply new configuration without needing a server restart or even user login.
Configuration storing format (can be files or DB):
- XML – that's what I was using in the past
- JSON - so I can read JSON from a config file or database and have it as an object in the app memory
- Key-Value pairs
- other formats?
What are your thoughts/knowledge about this subject?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
很久以前我写过一些类似的东西。它的目的不是分层的。它依赖于每个组件都有一个独特且合理的名称。那是在 XML 和 JSON 流行之前，所以我只使用 Properties。
本质上，您从顶部窗口开始，查看它的所有组件，然后根据它的类型（很多实例）调用一个方法（现在您可以给它一个更漂亮的名称，如“Marshaller”:-)）来编写找出用户可能更改并想要恢复的相关信息。递归应用。您会得到类似这样的信息：
您可能会欺骗它是分层的，但现在最好使用 XML 或 JSON。但基本概念可能适用。您可以使用 DIP 或其他东西来确定正确的编组器。
也许这会给你一些想法。也许没有一个标准的方法。令我惊讶的是，没有人回复“哦，是的，使用 Apache 这个或 Guava 那或 JGoodies”等。
A long time ago I wrote something to do similar. It wasn't intended to be hierarchical. It relied on every Component having a unique and reasonable name. This was before XML and JSON were trendy, so I just used Properties.
Essentially, you start at the top Window, look at all of it's Components, and, based on it's type (lots of instanceofs) call a method (nowadays you'd give it a fancier name like "Marshaller" :-)) to write out the relevant info that the user might change and want to restore. Apply recursively. You'll get something like:
You could probably finagle this to be hierarchical, but nowadays it's probably better to use XML or JSON. But the basic concept might apply. You could use DIP or something to determine the proper Marshaller.
Maybe this will give you a few ideas. Maybe there isn't a standard way. I'm surprised that nobody has responded with "oh yeah, use Apache this or Guava that or JGoodies" etc.
我是一个名为 Config4J 的配置文件解析器库的维护者。从您在问题中提供的详细信息来看，我认为 Config4J 并不 100% 适合您的需求。但是，其文档的某些部分可能会为您提供有用的灵感。
我建议您浏览一下“入门”手册的第 2 章和第 3 章，以获得对语法和 API 的充分概述。然后阅读“实际使用”手册的第二部分（“配置驱动的对象创建”）和第三部分（“Config4JMS 案例研究”）。 Config4J 网站 的底部提供了所有手册的 HTML 和 PDF 版本的链接。
I am the maintainer of a configuration-file parser library called Config4J. From the details you provide in your question, I don't think Config4J is 100% suitable for your needs. However, some parts of its documentation might provide useful inspiration for you.
I recommend you skim-read Chapters 2 and 3 of the "Getting Started" manual to gain a good-enough overview of the syntax and API. Then read Part II ("Configuration-driven Object Creation") and Part III ("The Config4JMS Case Study") of the "Practical Usage" manual. Links to HTML and PDF versions of all the manuals are provided at the bottom of the Config4J website.
好吧，总有 Java Preferences API。那么您就不必担心这些事情。
附录：
流行（或缺乏）可能源于这样一个事实：开箱即用的首选项在整个系统或用户中是全局的。因此，应用程序等需要在首选项树中创建自己的名称空间。人们更习惯于每个实例都有自己的属性文件并从那里开始。
对于更复杂的结构，Preferences API 是一个树结构，就像 XML DOM。您在树中找到了节点并在这些节点下工作。因此，您可以在该表示之上分层结构化数据。
该 API 很旧，就像 java 日志记录 API 很旧一样。但该设计非常基本且有用，因此没有太多需要对其进行更新的需求。集合框架也很旧，但我们每天（大部分时间）都快乐地生活着。
Well, there's always the Java Preferences API. Then you don't have to worry about any of these things.
Addenda:
The popularity (or lack of) likely stem from the fact that, out of the box, Preferences is global across the system or the user. So, applications and such would need to make their own namespaces within the Preferences tree. Folks are more used to each instance having their own properties file and going from there.
As for more complicated structures, the Preferences API is a tree structure, like an XML DOM. You located nodes in the tree and work below those nodes. So you can layer structured data on top of that representation.
The API is old much like the java logging API is old. But the design is pretty basic and useful, so there wasn't much call for updating it. The collections framework is old as well, but we live with that happily (mostly) every day.