# Wie beginnen?



## NeedAnswer (1. Sep 2012)

Hallo,
ich möchte eine Webplatform mit Hilfe von Java entwickeln.
Jetzt habe ich aber gesehen, dass dazu Java EE oder Spring verwendet werden kann.

Ich verstehe nicht genau den Unterschied zwischen den Technologien.
Java EE definiert doch die Technologien wie JSP, JSF ... , wie kommt jetzt Spring ins Spiel?
Was muss ich zuerst lernen, damit ich Spring verstehe? Gibt es in Spring JSF?
Java behersche ich ziemlich gut.
Für eine Aufklärung wäre ich sehr sehr dankbar.

Danke im Voraus


----------



## F.S.WhiTeY (1. Sep 2012)

Moin,

die Unterschiede sind schon ziehmlich deutlich. Es gibt aber auch Dinge die sich ähneln bzw. gliech sind. 

Gleich ist z.B. das sowohl Spring als auch JSF auf Servlets besaieren. Servlets sind das Grundgerüßt einer J2EE Platform. Desweiteren arbeiten beide Technologien mit EJB. 

Es ist theoretisch wie Praktisch möglich, das du dir deine eigene Platform entwickelst. Dafür musst du dich mit EJB und Servlets auskennen. 

JSF braucht nur zum Teil EJB's. Es arbeitet zwar im Hintergrund mit Servlets und EJB aber für dich als Entwickler kommen nur ManagedBeans zum tragen. ManagedBeans sind eine art EJB's allerdings etwas abgewandelt und mit eigenen Annotationen. Diese Annotationen ähneln sich zwar wieder, sind aber nicht in allen Punkten gleich. 

Spring hingegen setzt komplett auf EJB's. Wenn du also Spring lernen willst, brauchst du Grundwissen in der EJB technologie. 

Der meiner Meinung nach härteste Unterschied ist, dass Spring ein MVC-Framework für so gut wie alles ist. Spring kann nicht nur für J2EE eingesetzt werden. JSF hingegen ist ein UI-Framework für J2EE. Das bedeutet JSF stellt GUI-Komponenten bereit. Zu vergleichen mit AWT oder Swing. Das bedeutete JSF ist das V im MVC und lässt dir die entscheidung frei wie du M und C umsetzten kannst. 
Spring setzt das MVC komplett um und macht dir dahingehend gewisse Vorgaben. 

Daraus resultiert natürlich auch, das Spring in gewisser weise mächtiger ist. Damit aber auch aufwendiger zu lernen.

Jeh nachdem wie du drauf bist, wirst du wahrscheinlich mit JSF schnellere und schönere Erfolge erziehlen. Daher würde ich immer raten mit JSF anzufangen. 

JSP ist tot. Es kann zwar mit sicherheit nicht schaden sich JSP anzuschauen, das kann man allerdings machen wenn man JSF beherscht. Dann sind JSP keine herausforderung mehr und man kommt nicht durcheinander.

Danach würde ich mir EJB und Servlets genauer anschauen. Auch das ist mit einem gewissen Grundwissen um JSF leichter. Du kennst dann schon gewisse Muster wie den lifecycle und den Aufbau eines HTTP-Request. 
Danach ist Spring ein Klacks und du hast ein mächtiges Arsenal für die Web-Entwicklung. Mit Spring sogar weit darüber hinaus eine Waffe für das MVC-Pattern in allgemeinen Anwendungen. 

Fakt ist auf jeden fall, das du nicht an EJB vorbei kommst. EJB sind einfach Standard und mächtig. Also womit du anfängst ist eigentlich egal. Du kannst gewisse Punkte auch weg lassen. Nur Servlets und EJB sind essentziell.Wie ich allerdings erwähnt habe gibt es leichtere und schwerere Wege sich das Wissen aufzubauen. 

LG

David


----------



## Sym (1. Sep 2012)

F.S.WhiTeY hat gesagt.:


> Spring hingegen setzt komplett auf EJB's. Wenn du also Spring lernen willst, brauchst du Grundwissen in der EJB technologie.


Redest Du von Spring MVC? Spring selbst steht für sich alleine und ist nicht auf EJBs angewiesen. Oder verstehe ich Dich einfach falsch?

@TE: Wenn Du JSF einsetzen möchtest, besteht nicht unbedingt der Bedarf, Spring ebenfalls zu nutzen. Spring JSF als solches gibt es nicht. Spring MVC ist das Webframework von Spring und (meines Wissens nach) nicht kompatibel zu JSF.

Spring allgemein ist auch nur der Oberbegriff für ein Framework-Bundle und ist eher vergleichbar mit JEE (JSF und EJB) als mit den einzelnen Komponenten.

Empfehlen kann ich JSF 2.x und EJB 3.1. Ich persönlich arbeite damit lieber als mit Spring.


----------



## JohannisderKaeufer (1. Sep 2012)

Um Spring besser zu verstehen, sollte man es von der historischen Seite betrachten.

Applicationserver sind in der Regel nach einer J2EE-Spezifikation spezifiziert. Also J2EE beschreibt quasi einen Standard, den ein Applicationserver erfüllen muß. Wie eine Abgasnorm die ein neuzugelassenes Auto erfüllen muß.

Nun gibt und gab es immer Dinge, die man sich für einen Applicationserver gewünscht hat, die aber nicht, bzw. noch nicht in einer J2EE-Spezifikation beschrieben waren.

Nun gingen die Programmierer der Application-Server hin und haben teilweise eigene Lösungen dafür in ihr Produkt eingebaut.
Das hat auch soweit funktioniert, hatte allerdings den Nachteil, wenn man diese Features genutzt hat, dann war man oft auch an diesen einen Applicationserver gebunden.


Spring hat nun dieses Problem soweit gelöst, dass es diese gewünschten Features bereitgestellt hat ohne eine Abhängigkeit zu bestimmten Applicationservern zu schaffen. Vieles kann auch ohne einen Applicationserver verwendet werden. Teilweise kann durch den Einsatz von Spring, sogar auf einen Applicationserver verzichtet und stattdessen ein einfacher Webserver wie Tomcat oder Jetty genommen werden.


Mittlerweile ist es so, daß viele dieser Features, die Spring entwickelt hat auch in aktuelle J2EE-Spezifikationen Einzug gefunden haben.

Ein Beispiel ist Dependency Injection. 
Dependency Injection hat man sich immer schon gewünscht. Mit Spring konnte man dies schon eine ganze Weile machen. Die Dependencies wurden dabei in XML-Dateien gepflegt.
Heute ist es so, dass CDI in JEE vorhanden ist und für die Pflege der Abhängigkeiten z.B. Annotations genutzt werden.


An und für sich trifft es der Wikipediaartikel zu Spring recht gut:

Spring (Framework) ? Wikipedia


Heute ist es IMHO so, dass das aktuelle JEE für die meisten Benutzer kaum noch Wünsche offen läßt, so daß diese Spring nicht wirklich vermissen. Ein Punkt der für Spring spricht ist die Möglichkeit lediglich einen leichtgewichtigeren Tomcat statt einem Applicationserver zu nutzen.


----------



## F.S.WhiTeY (1. Sep 2012)

> Ein Punkt der für Spring spricht ist die Möglichkeit lediglich einen leichtgewichtigeren Tomcat statt einem Applicationserver zu nutzen.



Das kann ich auch, wenn ich JSF verwende. Ich brauche lediglich einen Servletcontainer und kann den rest selber schreiben. Das fängt bei Datenbankzugriff an, geht über Connectionpooling und hört bei der Absicherung der Applikation auf. 

Dafür brauche ich kein Spring wenn ich nicht will 

Ich teste alle meine J2EE-Anwendungen grundsätzlich auf dem Glassfish, JBoss und Tomcat und überall läuft es. Auch selbstgeschriebene Servlets laufen ohne Probleme. 

Welche erfahrungen hast du gemacht, dass du glaubst dich an einen Applicationserver binden zu müssen?



> Redest Du von Spring MVC? Spring selbst steht für sich alleine und ist nicht auf EJBs angewiesen. Oder verstehe ich Dich einfach falsch?



Im Grunde hast du recht, wenn man mit Spring allerdings eine Weile gearbeitet hat wird man feststellen dass man ohne eigene EJB's nicht weiter kommt. In fast jedem Spring buch gehen die Autoren  gleichzeitig auf EJB ein. 
Spätestens wenn man Extensions schreiben will braucht man EJB's. 

LG


----------



## Sym (2. Sep 2012)

F.S.WhiTeY hat gesagt.:


> Ich teste alle meine J2EE-Anwendungen grundsätzlich auf dem Glassfish, JBoss und Tomcat und überall läuft es. Auch selbstgeschriebene Servlets laufen ohne Probleme.


Das machst Du in beruflichen Projekten? So etwas ist mir nämlich noch nicht untergekommen und erscheint mir etwas zu viel des Guten. Meist entscheidet man sich für einen Server, weil eben alle Server ihre Eigenheiten haben.


----------



## F.S.WhiTeY (2. Sep 2012)

> Das machst Du in beruflichen Projekten? So etwas ist mir nämlich noch nicht untergekommen und erscheint mir etwas zu viel des Guten.



Das kommt darauf an ob du etwas entwickelst wo du die Infrastrucktur vorgaben darfst. Wenn ich etwas "Hausinternes" oder "zugeschnittenes" entwickel mag das zutreffen. Dann sag ich was da im Hintergrund läuft. Aber was wenn das jemand für sich entscheiden will? 

Plattformunabhängigkeit hört nicht beim Betriebssystem auf. Ich denke das ist auch eine Glaubensfrage 

Wobei ich zugebem muss, das es manchmal schon ein wenig nervig und/oder schwierig ist. Schon alleine die Pfadunterschiede zwischen Glassfish und Tomcat können einen in den Wahnsinn treiben xD

Das elaganteste ist natürlich alles embedded zu machen, dann hat man seine Ruhe. Das geht aber nicht immer. 

LG


Edit: P.S.: Denk einfach nur mal an IIS und Apachee. Ich hasse den IIS und liebe den Apachee, aber frag das mal einen MCSE.


----------

