Soll ich EJB3 oder Spring für meine Business-Schicht verwenden?

Mein Team entwickelt ein neues serviceorientiertes Produkt mit einem Web-Frontend. In Diskussionen darüber, welche Technologien wir verwenden werden, haben wir uns entschieden, einen JBoss-Anwendungsserver, ein Flex-Frontend (mit möglicher Desktop-Bereitstellung unter Verwendung von Adobe AIR) und Webdienste für die Schnittstelle zwischen Client und Server auszuführen.

Wir haben eine Sackgasse erreicht, wenn es darum geht, welche Servertechnologie für unsere Geschäftslogik verwendet werden soll. Das große Argument liegt zwischen EJB3 und Spring, wobei unsere größten Bedenken die Skalierbarkeit und Leistung sowie die Wartbarkeit der Codebasis sind.

Hier sind meine Fragen:

1. Was sind die Argumente für oder gegen EJB3 gegen Spring?
   • Welche Fallstricke kann ich mit jedem erwarten?
   • Wo finde ich gute Benchmark-Informationen?

Es wird keinen großen Unterschied zwischen EJB3 und Spring geben, basierend auf der Leistung. Wir haben uns aus folgenden Gründen für Spring entschieden (in der Frage nicht erwähnt):

• Spring treibt die Architektur in eine Richtung, die Unit-Tests leichter unterstützt. Fügen Sie beispielsweise ein nachgebildetes DAO-Objekt ein, um Ihre Geschäftsschicht zu testen, oder verwenden Sie das MockHttpRequest-Objekt von Spring, um ein Servlet zu testen. Wir pflegen eine separate Spring-Konfiguration für Komponententests, mit der wir Tests auf die spezifischen Ebenen isolieren können.
• Ein übergeordneter Treiber war die Kompatibilität. Wenn Sie mehr als einen App Server unterstützen müssen (oder eventuell die Option haben möchten, von JBoss zu Glassfish usw. zu wechseln), haben Sie Ihren Container (Spring) im Wesentlichen bei sich, anstatt sich auf die Kompatibilität zwischen verschiedenen Implementierungen von zu verlassen EJB3-Spezifikation.
• Spring ermöglicht die Auswahl von Technologien für Persistenz, Objekt-Remoting usw. Beispielsweise verwenden wir auch ein Flex-Frontend und das hessische Protokoll für die Kommunikation zwischen Flex und Spring.

Der Abstand zwischen EJB3 und Spring ist eindeutig viel kleiner als zuvor. Das heißt, einer der Nachteile von EJB3 ist jetzt, dass Sie nur in eine Bohne injizieren können, sodass Sie Komponenten in Bohnen verwandeln können, die es nicht müssen.

Das Argument über Unit-Tests ist derzeit ziemlich irrelevant - EJB3 ist eindeutig so konzipiert, dass es einfacher Unit-Tests möglich ist.

Das obige Kompatibilitätsargument ist ebenfalls irrelevant: Unabhängig davon, ob Sie EJB3 oder Spring verwenden, sind Sie immer noch auf Implementierungen von Transaktionsmanagern, JMS usw. angewiesen, die von Drittanbietern bereitgestellt werden.

Was es für mich jedoch schwingen würde, ist die Unterstützung durch die Community. Bei der Arbeit an einem EJB3-Projekt im letzten Jahr gab es einfach nicht viele Leute, die es nutzten und über ihre Probleme sprachen. Der Frühling ist zu Recht oder zu Unrecht weit verbreitet, insbesondere im Unternehmen, und das macht es einfacher, jemanden zu finden, der das gleiche Problem hat, das Sie lösen möchten.

Was sind die Argumente für oder gegen EJB3 gegen Spring? Der Frühling ist immer innovativ und erkennt reale Einschränkungen. Spring bot Einfachheit und Eleganz für die Java 1.4-Anwendungsserver und erforderte keine Version der J2EE-Spezifikation, auf die in den Jahren 2004 bis 2006 niemand Zugriff hatte. An diesem Punkt ist es fast eine religiöse Debatte, in die man hineingezogen werden kann - Spring + Abstraktion + Open Source versus Java Enterprise Edition (Java EE) 5.0-Spezifikationen.

Ich denke, dass Spring die Java EE-Spezifikationen mehr ergänzt als konkurriert . Da die Funktionen, die einst nur für Spring verfügbar waren, weiterhin in die Spezifikation aufgenommen werden, werden viele argumentieren, dass EJB 3 für die meisten internen Geschäftsanwendungen einen ausreichend guten Funktionsumfang bietet.

Welche Fallstricke kann ich mit jedem erwarten? Wenn Sie dies als Persistenzproblem (Spring + JPA) im Vergleich zu EJB3 behandeln, treffen Sie wirklich keine so große Wahl.

Wo finde ich gute Benchmark-Informationen? Ich habe die spezifischen Benchmark-Ergebnisse seit einiger Zeit nicht mehr verfolgt , aber sie waren für eine Weile beliebt. Es scheint, dass jeder Anbieter (IBM, JBOSS, Oracle und Sun) immer weniger an einem kompatiblen Server interessiert ist. Die Listen werden von zertifizierten Anbietern kürzer und kürzer, wenn Sie von 1.3, 1.4 wechseln. 1.5 Java Enterprise Edition. Ich denke, die Zeiten eines riesigen Servers, der alle Spezifikationen vollständig erfüllt, sind vorbei.

Ich würde EJB3 auf jeden Fall über den Frühling empfehlen. Wir finden, dass es schlanker, besser zu codieren und besser unterstützt wird. Ich habe in der Vergangenheit Spring verwendet und fand es sehr verwirrend und nicht so gut dokumentiert wie EJB3 (oder JPA, denke ich am Ende des Tages).

1. Ab EJB3 müssen Sie sich nicht mehr mit externen Konfigurationsdateien befassen, und es gibt nur ein POJO, das Sie pro Datenbanktabelle mit Anmerkungen versehen. Dieses POJO kann problemlos an Ihre Webschicht übergeben werden. IDEs wie Netbeans können diese POJOs sogar automatisch für Sie generieren. Wir haben EJB3 jetzt als Back-End für einige große Anwendungen verwendet und keine Leistungsprobleme festgestellt. Ihre Session Beans können problemlos als Webdienste verfügbar gemacht werden, die Sie Ihrem Flex-Frontend zur Verfügung stellen können. Session Beans können entweder auf Methoden- oder auf Klassenebene einfach gesperrt werden, um bei Bedarf Rollen und ähnliches zuzuweisen.

Ich kann nicht so viel über den Frühling sprechen, da ich ihn nur ein paar Wochen lang ausprobiert habe. Aber mein Gesamteindruck war sehr schlecht. Das bedeutet nicht, dass es sich um ein schlechtes Framework handelt, aber unser Team hier hat festgestellt, dass EJB3 das Beste für die Persistenz- / Geschäftsschicht ist.

Ich bevorzuge Spring gegenüber EJB3, aber meine Empfehlung wäre, egal welchen Ansatz Sie wählen, versuchen Sie, beim Schreiben von POJOs zu bleiben und verwenden Sie nach Möglichkeit die Standardanmerkungen wie JSR-Annotationen wie @PostConstruct, @PreDestroy und @Resource, die mit beiden EJB3 funktionieren oder Frühling, damit Sie auswählen können, welches Framework Sie bevorzugen.

Sie könnten sich beispielsweise für ein Projekt entscheiden, bei dem Guice stattdessen für IoC verwendet wird.

Wenn Sie die Voranforderungsinjektion verwenden möchten, z. B. in einer Webanwendung, ist Guice für die Abhängigkeitsinjektion möglicherweise wesentlich schneller als Spring.

Session Beans beschränken sich hauptsächlich auf Abhängigkeitsinjektion und Transaktionen. EJB3 und Spring sind sich also ziemlich ähnlich. Wo Spring die Nase vorn hat, liegt eine bessere Abhängigkeitsinjektion und schönere Abstraktionen für Dinge wie JMS

Ich habe in der Vergangenheit eine sehr ähnliche Architektur verwendet. Spring + Java 1.5 + Actionscript 2/3 in Kombination mit Flex Data Services machte das Codieren sehr einfach (und macht Spaß!). Ein Flex-Frontend bedeutet jedoch, dass Sie ausreichend leistungsfähige Client-Computer benötigen.

Was Ihre Frage betrifft:

Was sind die Argumente für oder gegen EJB3 gegen Spring?

Ich schlage vor, die Antwort der Experten zu lesen: EINE ANTWORT AUF: EJB 3 UND FRÜHLINGSVERGLEICHSANALYSE von Mark Fisher . Lesen Sie die Kommentare, um die Bemerkungen von Reza Rahman zu finden (EJB 3.0).

Eine andere Sache zugunsten der Feder ist, dass die meisten anderen Werkzeuge / Frameworks eine bessere Unterstützung für die Integration in die Feder bieten. Die meisten von ihnen verwenden die Feder auch intern (z. B. activemq, camel, CXF usw.).

Es ist auch ausgereifter und es stehen viel mehr Ressourcen (Bücher, Artikel, Best Practices usw.) und erfahrene Entwickler zur Verfügung als für EJB3.

Ich denke, EJB ist eine gute Komponententechnologie, aber kein gutes Framework. Spring ist das beste derzeit verfügbare Framework. Daher sollte ich Spring als die beste Implementierung von JEE im Sinne eines Frameworks betrachten, und meine Empfehlung ist, Spring in jedem zu verwenden Projekt, das uns die Flexibilität gibt, uns einfach in jede Komponententechnologie zu integrieren.