Wie viele EJBs sind zu viele?

Question

Ich entwickle gerade ein großes Stück Software auf JavaEE. Wir haben die allgemeinen Richtlinien von JavaEE befolgt, die besagen, dass jeder zugehörige Satz von Operationen in eine eigene EJB gehen sollte. Wir haben derzeit über 275 verschiedene EJB-Klassen (Stateless Session Beans). Diese Zahl wird wahrscheinlich auf mindestens das Doppelte dieser Zahl anwachsen.

Ich würde gerne wissen, ob die EJB-Container entworfen sind, um so viele verschiedene Arten von EJBs zu halten. Ich bin daran interessiert zu wissen, ob wir durch zu viele solcher Klassen eine schlechte Leistungseinbuße erleiden werden, und wenn einige Optimierungen auf der Ebene des Anwendungsservers diese hypothetischen Probleme lindern können.

Wir verwenden Glassfish v2 mit JavaEE 5 auf Suns Java 6, so dass Ratschläge zu dieser speziellen Plattform am meisten geschätzt werden.

Answer 1

EJBs sollten feinkörnig sein, so dass es kein Problem mit dem, was Sie tun, wenn Sie in Ihrem Design konsistent sind.

Die EJBs sind nur Klassen. Sie müssen sich also keine Sorgen machen, außer für die allgemeine Belastung, die orthogonal zur Anzahl der EJBs ist, die Sie bereitgestellt haben.

Wenn Sie sich Sorgen um die Leistung machen, stellen Sie einige Monitoring- oder andere Leistungsmesswerte ein und sehen Sie, wie die Dinge beim Hinzufügen neuer Funktionen ablaufen.

Am Ende des Tages, würden Sie lieber weniger Klassen mit vielen Methoden oder viele Klassen mit weniger Methoden beibehalten? Ich weiß, welchen ich wählen würde.

Answer 2

(Gibt es eine Weise, die ich „überhaupt“, ohne abgewählt sagen?)

Auf eine ernste Note, verwenden Sie so viele, wie Sie benötigen. Meine Faustregel ist (für EJBs und Klassen im Allgemeinen), wenn Sie nicht vollständig beschreiben können, was die Sache in einem Klassennamen von ungefähr drei Wörtern tut, haben Sie es zu viel tun.

Soweit die Leistung geht, vermute ich, dass, wenn das System beginnt zu leiden "zu viele EJBs" Sie haben viel größere Probleme irgendwo.

Answer 3

EJBs sind Komponenten und keine Klassen und Sie sollten in diesem Begriff an sie denken und Ihr Systemdesign entsprechend ausdrücken.

Die Granularität der Komponente ist offensichtlich domänenabhängig.

Angenommen, Sie modellieren einen (ziemlich altmodischen) Computer mit EJBs. Widerstände, Transistoren, Spulen, etc .: Das sind Pojos. Chips und Boards sind Komponenten. Die Versammlung ist das EAR.

Die Granularität der Schnittstelle sollte die Komponentenfunktion widerspiegeln.

Answer 4

EJB ist nicht nur normale Klasseninstanz. Es benötigt zusätzliche Wartung in Container, Instanzpool usw. Viele EJBs benötigen viel Ressourcen auf dem Server.

Ich glaube nicht, dass ein System Hunderte EJBs benötigen. Während ich auch an einer Anwendung mit 90 EJBs beteiligt war, war es ein Albtraum: < Es gab keine Testbarkeit und die Bereitstellung ist auch eine große Aufgabe.