2009-04-19 197 views
5

我目前正在開發基於JavaEE的大型軟件。我們遵循了JavaEE的一般準則,即每個相關的操作集都應該放入他們自己的EJB中。我們目前擁有超過275種不同的EJB類(無狀態會話bean)。這個數字很可能會增長到至少是這個數字的兩倍。有多少個EJB太多?

我想知道EJB容器是否被設計成容納許多不同種類的EJB。我很想知道是否會因爲擁有太多這樣的類而導致性能下降,並且如果某些應用程序服務器級別的調整可以幫助緩解這些假設問題。

我們在sun的Java 6上使用Glassfish v2和JavaEE 5,所以在這個特定平臺上的建議將非常感謝。

回答

5

EJB應該是細粒度的,所以如果你在設計中一致的話,你在做什麼沒有問題。

EJB只是類,所以除了一般負載(這與您部署的EJB的數量正交)之外,沒有什麼可擔心的。

如果您擔心性能,請添加一些監控或其他性能指標,並查看添加新功能時的情況。

在一天結束時,您會寧願使用許多方法維護更少的類,還是使用更少的方法維護更少的類?我知道我會選哪一個。

2

(有沒有一種方法,我可以說:「任何人在所有」而不被否決了?)

在一個嚴重的注意,用,因爲你需要儘可能多的。我的經驗法則是(對於EJB和通用類),如果你無法在三個詞的類名中完全描述該事物的作用,那麼你的做法太多了。

就性能而言,我懷疑如果系統開始遭受「太多EJB」的困擾,那麼在某處就會遇到更大的問題。

+0

+1爲「任何所有」評論 – tommym 2009-04-20 13:38:40

1

EJB是組件而不是類,您應該在該術語中考慮它們並適當地表達您的系統設計。

組件的粒度明顯依賴於域。

假設您使用EJB建模(相當老式)的計算機。電阻器,晶體管,線圈等:這些是pojos。芯片和電路板是組件。該組件是EAR。

接口粒度應反映組件功能。

1

EJB不僅僅是普通的類實例。它需要在容器,實例池等中進行額外的維護。許多EJB在服務器上需要很多資源。

我不認爲系統需要數百個EJB。雖然我還參與了一個包含90個EJB的應用程序,但這是一場噩夢:<沒有可測試性,部署也是一項艱鉅的任務。