it-swarm.com.de

Java EE 6 vs. Spring 3 Stack

Ich beginne jetzt ein neues Projekt. Ich muss mich für Technologien entscheiden. Ich brauche etwas Leichtes, also kein EJB oder Seam. Andererseits benötige ich JPA (Hibernate oder Alternative) und JSF mit IceFaces.

Halten Sie einen solchen Stack für Spring 3, der auf Tomcat bereitgestellt wird, für eine gute Wahl? Oder eine Java EE 6-Webanwendung könnte besser sein? Ich befürchte, dass Java EE 6 eine neue Technologie ist, die noch nicht gut dokumentiert ist. Tomcat scheint einfacher zu pflegen als Glassfish 3.

Was ist deine Meinung? Hast du irgendwelche Erfahrungen?

87
Piotr Gwiazda

Ich brauche etwas Leichtes, also kein EJB oder Seam.

Möchten Sie erklären, was EJBs seit EJB3 so schwer macht? Ist Ihnen klar, dass wir nicht mehr im Jahr 2004 sind? Ich würde wirklich gerne Ihre Definition von Licht und Ihre Argumente lesen (und ich werde meine Antwort mit Vergnügen aktualisieren, weil ich mir ziemlich sicher bin, dass ich das getan hätte) ein paar solide Dinge zu sagen).

Andererseits benötige ich JPA (Hibernate oder Alternative) und JSF mit IceFaces.

Java EE 6 Web Profile, das JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI usw. enthält, ist hierfür perfekt geeignet. Sie können GlassFish v3 Web Profile verwenden, um eine erstellte Anwendung auszuführen mit dem Java EE 6 Web Profile.

Halten Sie einen solchen Stack für Spring 3, der auf Tomcat bereitgestellt wird, für eine gute Wahl? Oder eine Java EE 6-Webanwendung könnte besser sein?

Nun, [~ # ~] i [~ # ~] mag die Idee, meinen Code auf einer nicht-proprietären Plattform (Java EE) anstatt auf einem proprietären Container (Frühling). Und ich denke, dass Java EE 6 ist gut genug (und das ist ein Euphemismus, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass.) Beachten Sie, dass ich ein JSF-Skeptiker war Aber ich habe einen zweiten Blick darauf geworfen und JSF 2.0 mit CDI ist so anders, dass ich es nicht einmal vergleichen kann. Und wenn Sie sich CDI nicht angesehen haben, lassen Sie mich Ihnen sagen, dass es rockt.

Ich befürchte, dass Java EE 6 eine neue Technologie ist, die noch nicht gut dokumentiert ist.

Java EE sieht für mich ziemlich gut dokumentiert aus. Das klingt nach freiem Anspruch. Und ob Sie es glauben oder nicht, [~ # ~] i [~ # ~] es wird immer schwieriger, den Frühling zu entdecken, während Java EE) immer einfacher wird.

Tomcat scheint einfacher zu warten zu sein als Glassfish 3.

Hast du etwas ausprobiert? Konnten Sie ein bestimmtes Problem feststellen? Auch dies klingt nach freiem Anspruch.

101
Pascal Thivent

Ich habe JavaEE6 nicht verwendet.

Ich wurde jedoch von allen früheren Versionen von JavaEE und EJB so sehr zusammengeschlagen, dass ich ihm erst vertrauen kann, wenn er sich als De-facto-Standard und nicht nur als De-jure-Standard etabliert hat. Im Moment ist der Frühling immer noch der De-facto-Standard.

Täuschen Sie mich einmal Schande über Sie. Täusche mich zweimal, schäme dich für mich. Mach mich dreimal zum Narren, EJB.

Einige werden behaupten, dass Spring proprietär ist. Ich würde behaupten, dass die Herstellerimplementierungen der JavaEE-Spezifikationen genauso proprietär waren, wenn nicht mehr.

Vor kurzem habe ich eine umfassende Umstellung vorgenommen, bei der eine Reihe von Java) - Anwendungen von JBoss nach Weblogic verschoben wurden. Alle Spring/Hibernate-Apps wurden ohne Änderungen portiert, da alle benötigten Bibliotheken eingebaut waren Alle Apps, die JPA, EJB und JSF verwendeten, stellten eine Katastrophe dar. Geringe Unterschiede bei der Interpretation von JPA, EJB und JSF zwischen Anwendungsservern führten zu bösen Fehlern, deren Behebung ewig dauerte völlig anders zwischen AppServers.

Frühling ist eine Umsetzung. JavaEE ist eine Spezifikation. Das ist ein RIESIGER Unterschied. Ich würde es vorziehen, eine Spezifikation zu verwenden, WENN die Spezifikation 100% luftdicht ist und absolut keinen Spielraum für die Art und Weise gibt, wie Anbieter diese Spezifikation implementieren. Aber die JavaEE-Spezifikation war noch nie so. Vielleicht ist JavaEE6 luftdichter? Ich weiß es nicht. Je mehr Sie in Ihre WAR-Datei packen können und je weniger Sie von AppServer-Bibliotheken abhängig sind, desto portabler wird Ihre Anwendung, und schließlich verwende ich Java und nicht Dot -NETZ.

Selbst wenn die Spezifikation luftdicht ist, wäre es schön, den App-Server aktualisieren zu können, ohne alle meine Technologie-Stacks in allen meinen Anwendungen mit aktualisieren zu müssen. Wenn ich ein Upgrade von JBoss 4.2 auf JBoss 7.0 durchführen möchte, muss ich die Auswirkungen der neueren Version von JSF auf alle meine Anwendungen berücksichtigen. Ich muss die Auswirkungen auf meine Spring-MVC-Anwendungen (oder Struts-Anwendungen) nicht berücksichtigen.

32
Beaker

Es spielt keine Rolle. Java EE 6 ist gut genug und aufgrund der dortigen Profile nicht "schwer" - Sie werden nur das Webprofil verwenden.

Ich persönlich bevorzuge den Frühling. Aber ich habe keine rationalen Argumente mehr gegen Java EE 6 :)

(Wie ich durch einen Kommentar erinnert wurde - Sie möchten vielleicht versuchen RichFaces , sowie ICEfaces und/oder PrimeFaces - je nachdem, welche Komponenten du brauchst).

23
Bozho

Kürzlich umfasste eine meiner Kundenaufgaben die Evaluierung von Spring Stack Vs Custom Framework Stack Vs a Java EE-Standards. Nach einem Monat Evaluierung und Prototyping war ich nicht nur glücklich, sondern überwältigt vom Funktionsumfang von Java EE 6. Für jede neue "Enterprise" -Projektarchitektur im Jahr 2011 und in Zukunft würde ich Java EE 6 und potenzielle Erweiterungen wie Seam 3 oder das bevorstehende Apache JSR299-Erweiterungsprojekt verwenden. Java EE 6 Die Architektur wurde optimiert und enthält das Beste aus vielen Open-Source-Ideen, die in den letzten Jahren entwickelt wurden.

Berücksichtigen Sie die folgenden sofort einsatzbereiten Funktionen: Event Management, Contexts und DI, Interceptors, Decorators, RESTful-Webservices, integriertes Testen mit einbettbarem Container, Sicherheit und vieles mehr.

Die meisten meiner Ergebnisse sind veröffentlicht in meinem Blog Erklären der Schlüsselkonzepte von Java EE 6, die Sie vielleicht nützlich finden.

Natürlich gibt es keine feste Regel für die Auswahl eines Frameworks. Java EE 6 könnte für einfachere "Websites" gut aufgebläht sein, die keinen umfassenden Status für Konversationssitzungen erfordern. Sie können auch Grails oder Play auswählen! Rahmen. Aber für Konversationswebanwendungen kann ich kein besseres Argument sehen, warum Java EE 6 nicht gut passt.

17
pri

Jetzt, nach einiger Zeit, habe ich Erfahrung mit Stacks:

  • Java EE 5 + Seam + GraniteDS + Flex
  • Frühling 3 + Vaadin (auf GWT)
  • Frühling 3 + JSF 2.0 (PrimeFaces)

Meine Schlussfolgerungen sind:

  • Spring 3 ist viel einfacher als Seam (fast Java EE 6) und läuft auf Tomcat und Jetty! (Jetty für die Entwicklung mit Maven-Plugin ist eine Kleinigkeit).
  • Ich liebe Flex (ich war eigentlich lange Zeit ein Flex-Entwickler, also bin ich voreingenommen) und wenn Sie ein reichhaltiges Interface benötigen und FlashBuilder kaufen können, verwenden Sie dieses, aber verwenden Sie dieses Spring + GraniteDS- oder BlazeDs-Backend. Wenn Sie FlashBuilder nicht kaufen können, verlieren Sie keine Zeit.
  • Vaadin ist großartig !. Der Entwicklungsprozess ist einfacher als bei Flex, Sie können jedoch problemlos umfangreiche Anwendungen ohne HTML-Probleme erstellen. Sie werden keine einzige JS-Zeile schreiben. Sie brauchen nur etwas CSS (in Flex brauchen Sie es auch). Wenn sich Ihre Anwendungsoberfläche also wie eine Desktop-Anwendung verhält und Sie Flex nicht verwenden können (oder wollen), verwenden Sie Vaadin. Warnung! Vaadin hat einen hohen JS-Aufwand für den Browser.
  • Wenn Sie eine einfachere, website-ähnliche Anwendung erstellen, verwenden Sie JSF2.0 (mit Spring-Backend wie oben). Sie müssen mit HTML kämpfen (ich hasse es) und die Erstellung einer umfangreichen Benutzeroberfläche wird schwieriger sein als Vaadin (insbesondere Layouts). Sie erhalten leichtes HTML für langsamere Browser/Computer. Ich mag PrimeFaces - es ist einfach und gut dokumentiert. Der zweite Platz ist IceFaces
  • Wenn Sie eine Website (NICHT eine Webanwendung) erstellen, auf der Sie HTML-Code verwenden müssen (anstatt eine Unternehmensanwendung zu erstellen, die in den Browser passt), verwenden Sie Wicket (wenn Sie komponentenbasiert, Pull-Einstellung bevorzugen) oder SpringMVC (wenn Sie vorlagenbasiert bevorzugen) , Push Attitude) oder benutze einfach Play! Rahmen. Denken Sie daran, dass das Erstellen umfangreicher datenbasierter Komponenten viel schwieriger sein wird, Sie jedoch die Kontrolle über jedes HTML-Tag haben werden (Ihr HTML-/Grafikdesigner wird begeistert sein).
15
Piotr Gwiazda

Meine Meinung basiert auf etwas, was von anderen nicht erwähnt wurde, nämlich dass Code bei meiner Arbeit in der Regel Jahrzehnte lang (im wahrsten Sinne des Wortes) lebt und daher die Wartung für uns sehr wichtig ist. Pflege unseres eigenen Codes und der von uns verwendeten Bibliotheken. Wir kontrollieren unseren eigenen Code, aber es liegt in unserem Interesse, dass die Bibliotheken, die wir verwenden, von anderen in den oben genannten Jahrzehnten oder mehr gepflegt werden.

Um es kurz zu machen, ich bin zu dem Schluss gekommen, dass der beste Weg, dies zu erreichen, darin besteht, Open-Source-Implementierungen von Sun-Spezifikationen bis hinunter zur unformatierten JVM zu verwenden.

Von den Open-Source-Implementierungen hat Apache Jakarta bewiesen, dass sie ihre Bibliotheken beibehalten, und Sun hat in letzter Zeit viel Arbeit bei der Erstellung hochwertiger Implementierungen für Glassfish v3 geleistet. In jedem Fall haben wir auch die Quelle für alle Module, sodass wir sie selbst warten können, wenn alles andere fehlschlägt.

Sun-Spezifikationen sind normalerweise sehr streng, was bedeutet, dass Implementierungen, die den Spezifikationen entsprechen, leicht ausgetauscht werden können. Schauen Sie sich einfach die Servlet-Container an.

In diesem speziellen Fall würde ich vorschlagen, sich JavaServer Faces anzuschauen, nur weil es Teil von Java EE 6 ist, was bedeutet, dass es für eine sehr, sehr lange Zeit verfügbar und gepflegt sein wird. Dann haben wir Es wurde ausgewählt, um MyFaces Tomahawk zu erweitern, da es einige nützliche Ergänzungen enthält und ein Jakarta-Projekt ist.

Es ist nichts falsch mit JBoss Seam oder anderen. Es ist nur so, dass ihr Fokus weniger auf das Wartungsproblem gerichtet ist, das uns so wichtig ist.

Lesen Sie Adam Biens Future Of Enterprise Java ... ist klar (Java EE mit/ohne Spring und umgekehrt) , einschließlich Kommentaren, um beide Seiten der Medaille zu erhalten Ich werde aus verschiedenen Gründen den Frühling wählen. Im Folgenden ist einer davon aufgeführt.

"Ich bin nicht sicher, von welchem ​​Java EE 6-Server Sie sprechen. Es gibt Glassfish-zertifizierte und TMAX-JEUS. Es wird eine Weile dauern (gelesen: Jahre), bis Java EE 6-kompatible Versionen von WebSphere, WebLogic, JBoss usw. sind in der Produktion und können für echte Anwendungen verwendet werden. Spring 3 benötigt nur Java 1.5 und J2EE 1.4 können problemlos verwendet werden fast alle Umgebungen

8
Adi

Ich kann Spring verwenden, wenn Sie es bereits haben, aber für das neue Projekt, was ist der Sinn? Ich würde direkt mit Java EE 6 (ejb3, jsf2.0, etc.)

Wenn der Client mit Flex zufrieden ist, entscheiden Sie sich dafür. Benutze BlazeDS oder ähnliches - kein MVC. Möglicherweise verbringen Sie mehr Zeit mit diesem Teil (Datenaustausch zwischen Server und Client), haben aber auf beiden Seiten die volle Kontrolle.

Verwenden Sie Vaadin nur, wenn Sie Ihren Browser beenden möchten. Außerdem verbringen Sie mehr Zeit damit, sich im Code zurechtzufinden, sobald Ihre Seiten komplexer werden. Außerdem muss Ihre Denkweise komplett geändert werden, und alles, was Sie über die Standard-Front-End-Entwicklung wissen, ist Verschwendung. Das Argument, dass Sie kein HTML oder JS verwenden müssen, ist wenig sinnvoll. Sie müssen es immer noch wissen, auch wenn Sie es nicht verwenden. Es wird schließlich in HTML und JS gerendert. Dann versuchen Sie es zu debuggen - stellen Sie sicher, dass Sie ein paar Tage Zeit für einfache Dinge haben. Außerdem kann ich mir keinen Webentwickler vorstellen, der HTML/JS nicht kennt.

Ich verstehe nur nicht, warum die Leute all diese Abstraktionen ausprobieren, anstatt Java EE direkt zu verwenden.

6

Warum gibt es immer noch Gerüchte über EJB im Schwergewicht im Jahr 2010? Es sieht so aus, als würden die Leute nicht in Java EE-Technologien aktualisiert. Probieren Sie es einfach aus, Sie werden angenehm überrascht sein, wie die Dinge in Java EE 6 vereinfacht werden.

5
nash

Die Antwort auf Ihre Fragen hängt von Ihren Projektanforderungen ab. Wenn Sie die Java EE-Funktionen wie Nachrichtenwarteschlangen, containergesteuerte globale Transaktionen usw. nicht benötigen, wählen Sie Tomcat + spring.

Auch aus Erfahrung habe ich herausgefunden, dass Projekte, die viel Web-Service-Integration, Zeitplanung und Nachrichtenwarteschlangen erfordern, am besten mit Hilfe des Java= EE-Stacks durchgeführt werden. Das Gute ist, dass Sie spring you can verwenden Integration mit Java EE-Modulen, die auf einem Anwendungsserver ausgeführt werden.

Java EE 6 unterscheidet sich stark von den Vorgängerversionen und macht alles sehr viel einfacher. Java EE 6 vereint die besten Ideen aus der vielfältigen Java Community - Rod Johnson vom Spring Framework war beispielsweise aktiv an der Erstellung des Dependency Injection JSR in beteiligt Java EE 6. Ein Vorteil der Verwendung von Java EE 6 besteht darin, dass Sie nach einem Standard codieren, der in einigen Organisationen für die Unterstützung von Anbietern usw. wichtig sein kann .

GlassFish v3 unterstützt Java EE 6 und es ist recht leicht und startet sehr schnell. Ich habe glassfish v3 für meine Entwicklungen verwendet und es ist sehr einfach zu konfigurieren Sehr benutzerfreundliche Administrationskonsole, mit der Sie Ihren Server grafisch verwalten können.

Wenn Sie GlassfishV3 und JSF 2 verwenden, können Sie die CDI-Funktionen von Java EE 6) nutzen, mit denen Sie auf einfache Weise Unterhaltungen (z. B. Seiten wie von Assistenten) in JSF erstellen können.

Allerdings müssen Sie für die Verwendung von Java EE 6 auch eine neue API erlernen. Abhängig vom verfügbaren Zeitrahmen ist dies möglicherweise nicht die beste Wahl für Sie. Tomcat gibt es schon seit Ewigkeiten Tomcat + Federkombination wurde von vielen Webprojekten übernommen, was bedeutet, dass es viele Dokumentationen/Foren gibt.

4
Raz

Wenn Sie den Java EE Full Stack benötigen, empfehle ich Ihnen GlassFish 3.1. Verglichen mit anderen Java EE-Containern, die einen Teil oder alle Java EE 6 (JBoss 6, WebLogic 10.3.4) implementieren, beginnt die Neuverteilung sehr schnell und fast alle können durchgeführt werden Konvention über Konfiguration ist es sehr freundlich.

Wenn Sie etwas "Leichtes" möchten, können Sie einen Apache Tomcat 7.x mit den gewünschten Funktionen anpassen. Ich habe viel mit den folgenden Bibliotheken gearbeitet: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - nur ressourcenlokale Transaktionen JSF 2.x (Mojarra) RichFaces 4.0 BIRT-Laufzeit

Ich bin seit 10 Jahren ein Java EE-Entwickler (ich leide an frühen EJB-, JSF- und Web-Technologien). Java EE 6 ist sehr einfach, gut gekoppelt und die aktuelle Hardware läuft reibungslos, so originell Gründe, die motivierten Frühling nicht mehr gültig sind.

3
ssamayoa

Ich habe sowohl in Spring als auch in Java EE 6 gearbeitet. Was ich aus meiner Erfahrung sagen kann, ist, dass Sie sicher sind, wenn Sie bei Spring bleiben, wenn Sie sich für die uralte JSP oder proprietäre Flex entscheiden .

Wenn Sie jedoch mit JSF weitermachen möchten, müssen Sie zu Java EE 6 wechseln. Mit Java EE 6 wechseln Sie zu Facelets und standardisierten Skriptbibliotheken und Komponentenbibliotheken: Keine Skriptinkompatibilitäten und Komponentenbibliotheksmatrizen mehr.

In Bezug auf Spring MVC ist es gut, solange Ihr Projekt nicht zu groß wird. Wenn es sich um eine große Unternehmensanwendung handelt, bleiben Sie bei Java= EE 6. Denn nur so können Sie Ihre eigenen Komponentenbibliotheken und Ressourcenbündel ordnungsgemäß verwalten.

3
user373480

Ich würde den Frühling immer noch vorziehen.

Und ich würde JSF weitergeben. Ich denke, es ist eine tote Technologie. Spring MVC wäre eine bessere Alternative. Also würde Flex. Denken Sie in Bezug auf den Vertrag zuerst an XML-Services, und Sie können das Back-End vollständig von der Benutzeroberfläche entkoppeln.

1
duffymo

Ich habe nicht alles gelesen, sondern nur, um zu verdeutlichen, dass Sie EJB3 jetzt in einem Krieg gegen Java EE 6) verwenden können, damit Sie EJB3 auf Tomcat verwenden können (glaube ich).

0

Ich würde Spring + Tomcat empfehlen, es sei denn, Sie können die Zeit abwarten, bis Glassfish v3 und Weld reifer werden. Beim Ausführen von glassfish mit CDI-fähigen Anwendungen treten derzeit einige Probleme mit dem Speicherverbrauch/der CPU-Auslastung auf.

0
beamso