在Java

所以我建立各种索引和摄入Java中的类为Accumulo 在Java

但我的问题是没有直接关系处理复杂的配置优化方法。

我有一个属性文件存储关键字和数据库表名称的长列表（比方说，好一打，增长）。

现在，当我的主类被实例化时，我将所有这些属性读入其相关的String对象，并在整个过程中使用它们。然而，其中一些项目需要传递下来，有时以大块形式传递给其他类。

我想，我的选择是

去吧，我现在，这似乎是坏的，因为如果我在错误的顺序，可能会出现各种污秽提交令牌。
传递属性对象本身，并让每个类处理实例化它自己的字符串对象（如果令牌被添加或从文件中删除，很容易成为未来维护的痛苦）。
移动到将信息存储在JSON文件中，该文件作为一个特殊的类对象被读入，并传递给需要从中获取信息的任何人（小缺点是每个类都会根据表名称创建表引用根据需要，在使用JSON的情况下，继续并实例化所有表引用以便类可以请求引用，但在不需要时会经常创建一些额外的引用）可能是有意义的。）
某些其他选项Java专家知道我不知道

我很在意这一点，因为在过去我主要是嵌入式和小型系统的C++开发人员。这是我的第一个大规模项目之一，所以我试图从一开始就做好事情。我已经有一堆书籍，包括设计模式，只是为了让我的脚湿，但任何一般的编程实践知识库，我会很乐意采取建议。

我试图使这个概括，以便其他人可以受益，但可能需要一些更多的细节，让我知道。

来源

2012-10-17 FaultyJuggler

选项（2）似乎是一个好方法。

其中的一个变体是从主Properties对象中提取所有字符串到单独的Properties（或HashMap）对象中，这可能是基于元素名称的前缀。因此，类Foo获取名称前缀为foo.的所有属性，类Bar获取所有bar.xxx属性，依此类推。

这使逻辑上（和物理上）分离集合中的属性保持不变，并仅为给定的类提供所需的属性。如果所有类都需要共享公共属性（可能是前缀为all.或global.，或者根本没有前缀），那么可以将这些属性添加到每个单独的Properties对象中。

来源

2012-10-17 23:45:14

许多表和关键字跨多个类共享的，只是不是所有的人。就像我正在处理的数据一样，属性文件中项目的使用非常稀疏，我将主要关注将来的可维护性，无论是随着属性文件的增长，还是值的变化或消失。我想通过更多的真正的解决方案可能是进一步分解课程，使每个只需要少量的整体属性，然后所有的维护都在主类，这不会是一个头痛的问题。 – FaultyJuggler

您的复杂性级别要求您直接处理java.util.Properties文件。

这是一个简单的对象，它应该根据需要进行缩放。我不建议将你的属性映射到Java对象，因为你最终会不断地改变映射文件;您需要只有java.util.Map才能提供的全部灵活性。

顺便说一句，你需要这个事实，听起来不正确。可能有一个全球设计问题需要在您的应用程序中重新考虑。因为在层次结构树中构造属性可能有助于降低配置文件的复杂性，但同样我会避免将json对象映射到Java对象，因为您的模型是经常改变（据我所知）。

您可能会尝试在配置属性之间找到“模式”并尝试提取某个组织。一旦你猜到了你的配置中构建的一些好的“业务对象”，你可以将配置减少到这些对象的数组。

JSON听起来适合我。你的问题可以被看作是“复杂配置”的原型，这并不罕见（想想maven中的pom.xml）。因此，您需要在我看来，两件事情：在您的配置

提取一些组织
使用一些结构化的配置格式（如JSON或XML）

来源

2013-01-27 15:41:18

我继续使用属性文件方法，并且每次需要添加和更改某些内容时都大大减少了维护工作量，但仍然感觉不到无缝。没有太多结构，它实际上只是一长串关键值对，保留数据库表名或跨多个类使用的关键字。倾向于属性文件的另一个原因是十多个类需要相同和不同的信息部分 – FaultyJuggler

我正在考虑为OWNER API（http://owner.aeonbits.org）添加一些“嵌套”的可能性，因此您可以拥有“嵌套属性”或将单个属性文件建模为嵌套对象结构。目前这种情况已不存在，但我正在考虑如何以最佳形式实施这一做法。 –

正如我所提到的，这里没有嵌套，只是一个随着时间的推移而逐渐增长和变化的纯粹列表。 – FaultyJuggler

Commons Configuration有几个特点，可以帮助您组织

独立于源配置数据（属性文件，XML文件，数据库，...）
分层特性
声明和创建豆

来源

2013-03-05 16:24:46 fglez

回答

相关问题