在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

回答

相關問題