2011-03-14 77 views
1

我目前正在研究一個應用程序,其中域對象D的一個實例被注入到應用程序中。域對象可以包含許多不同的組合,並按其bean定義的不同組合和排列組合,從而導致許多不同的最終對象D,我稱它們爲不同的D版本。對於D的給定版本,我必須填滿原始值並將其保存到數據庫中。使用JPA和Hibernate將它保存到數據庫非常簡單。問題是填寫D中的值。使用SNMP通過網絡獲取值,然後填滿。對於D的每個版本,都有不同的策略可以遵循,因爲D的每個版本都可能有不同的MIB。我目前正在遵循工廠模式。工廠採用D版本並返回一個特定於該D版本的valueRetriever,然後用於獲取值並填充D.在Spring中使用依賴注入來替換工廠模式

另一個明顯的方法是在D中注入配置檢索器,然後用它來檢索配置。但是我還需要在運行時使用檢索器來重新獲取配置,這樣就有必要將檢索器存儲在數據庫中,因此爲每個檢索器創建一個新表,這似乎是目前的開銷。

我的問題是:有沒有更好的方法來檢索配置,即有一個valueRetriever給定了上述使用依賴注入的場景。

編輯:AOP可以在這裏使用嗎?

回答

2

看來您需要創建的某些對象具有複雜的創建邏輯。您可能不會去查看Spring FactoryBean接口,因爲FactoryBean可以通過網絡獲取所有複雜的細節,同時允許您創建實例並將其注入其他bean。

+0

在定義bean的實例化過程中,這可能是好的,但在將其保存到數據庫之後會發生什麼?在存儲之後,爲了在運行時檢索值,即在從數據庫中加載D之後,將這個基於BeanFactory的Factory仍然能夠提供檢索器?如果這不是真的,那麼我將不得不以某種方式找到一種方法來保持工廠或檢索器與D.這將是非常類似於注入與D本身的檢索器作爲將使用的檢索器,但將該檢索器保存在那麼DB是必要的。 – 2011-03-14 18:33:51

0

Spring的DI 的基礎是 Bean Factory/Application Context,因此完全可以替換你正在做的事情。

區別在於您必須能夠將所有排列放入Spring配置中並將控制權交給應用程序上下文。如果你不能這樣做,也許你的解決方案是首選。

更新:我會開始擔心你的Spring解決方案將過多的陌生技術添加到可能過於複雜的情況中。

吸一口氣,認爲「簡單」。

我現在不擔心數據庫。如果您可以將所需的所有組合放入bean工廠,則Spring應用程序上下文將成爲數據庫。我假設這些配置是隻讀的,一旦聲明它們就不會改變。如果不是這樣,所有投注都關閉。

+0

是的,如果對象總是從應用程序上下文創建,那麼BeanFactory可能會非常有用,因爲它可以在沒有任何額外代碼的情況下連線檢索器。但是,當我從數據庫中加載對象時,這也可以工作嗎?這個BeanFactory會爲該對象提供檢索器嗎?在這種情況下,Spring應用程序上下文不會發揮作用,所以我將不得不使用域對象本身保存一些存儲在數據庫中的實體。 – 2011-03-14 18:59:17

+0

如何從數據庫加載它們 - 一個持久存儲 - 與從Spring配置初始化它們有什麼不同?你堅持認爲這是必要的,但我仍然沒有看到原因。請解釋除「我這麼說」或「這是我如何做」之外的其他內容。我很想讀一個有說服力的解釋。 – duffymo 2011-03-14 19:47:51

+0

我實際上要求澄清一下BeanFactory。我的意思是,當我使用entityManager.load(id)時,BeanFactory如何調用,而不是使用後加載攔截器。 BeanFactory是在第一個實例化過程中定義這個對象的bean中定義的。在這種情況下它是如何發揮作用的?我沒有使用BeanFactory,所以我可能會錯過很多天真的觀點。請多多包涵。 – 2011-03-14 20:03:28