Ich bin sehr verwirrt - struts, jsp, jsf . ?

[Hilefoks]

Moin,

ich bin sehr verwirrt. Ich komme aus der C & C++ Ecke und kenne mich da auch recht gut aus. Java habe ich bisher immer recht stiefmütterlich behandelt. Nun möchte ich aber doch mal in die Java-Welt eintauchen. Da mir Java für die einfachen Desktop-Applications nicht gefällt (da ist mir C++ & Qt lieber) und ich schon lange einen Ersatz für Scriptsprachen im Webbereich suche möchte ich hier mein Glück in Java suchen & finden.

Überall findet man als Java-Neuling die Schlagworte JSP, JSF, Struts, Hibernate, Beans, Spring, EJB, usw. Leider finde ich aber irgendwie nicht den passenden Einstieg und zudem ist mir bei vielen dieser Schlagwörter nicht klar wie sie in Relation zueinander stehen oder gesetzt werden müssen. Natürlich finde ich, z.B. in der Wikipedia, einleitende Informationen zu jedem dieser Technologien. Allerdings finde ich keine Informationen wie und was "zusammen" gehört. Muss ich, um mich mit Struts zu beschäftigen, zunächst JSP oder JSF kennen? Sind die JSF eine "Obermenge" zu JSP oder eine eigenständige, parallele Entwicklung und wie gehört Struts dort hinein? etc.

Wer könnte mir das in kurzen Worten mal etwas aufschlüsseln?

MfG,
Hilefoks

 

[miketech]

Hehe, das kenn ich nur zu gut.

(Bestätigt eigentlich nur zunehmend die Theorie, dass die Vielfalt in der Java-Welt eher negativ, als positiv ist)

Also was ich Dir sagen kann:

JSP ist für dynamische Webseiten, ähnlich wie PHP. Du hast ne Webseite und baust dort Java-Code ein, um dynamisch Inhalte zu erzeugen. Mit JSF habe ich selbst noch nicht gearbeitet, klingt aber sehr interessant. Es erinnert stark an ASP.NET falls Du das kennst.

Hibernate ist ein Object-Relational-Mapper. D.h. angenommen Du hast eine Tabelle in der Datenbank Users, mit den Spalten "Name", "Wohnort". Nun möchtest Du in Deinem Programm auch eine Klasse User verwenden mit den Attributen "name" und "wohnort". Normal müsstest Du dann nach z.B. einem Select Statement jedes mal die Felder per Hand füllen:

user.setName(currentRowSpalte1);
user.setWohnort(currentRowSpalte2);

Das kann ja sehr schnell kompliziert werden, auch wenn Du den umgekehrten Weg wieder vor hast, sprich Du hast ein Objekt vom Typ User und möchtest das in Deiner Tabelle speichern. Dafür gibt es Hibernate, dass Du diese Umwandlung nicht per Hand machen musst.

Ich hoffe, ich erzähle hier keinen Blödsinn Selbst habe ich nämlich noch nicht damit gearbeitet.


Was ich aber viel mehr sagen möchte: Wenn Dir Qt gefällt und Du mit Java arbeiten möchtest, ist vielleicht QtJambi was für Dich. Ist das offizielle Qt Binding für Java, von Trolltech selbst entwickelt. D.h. Du programmierst Qt mit Java. Es gibt auch ein Eclipse Plugin für den Designer. Ich hab mal einen Screenshot hochgeladen:

http://www.miketech.net/pics/QtJambi.png

Gruß

Mike

 

[Gast]

(Bestätigt eigentlich nur zunehmend die Theorie, dass die Vielfalt in der Java-Welt eher negativ, als positiv ist)

Für Einsteiger ist es negativ für Entwickler schon positiv, zumal man ja auch nicht alles verwenden und kennen muss.

 

[miketech]

Hi,

aber auch für entsprechende Personen, die zu entscheiden haben, ob nun z.B. für das nächste Projekt Java gewählt werden soll. Bei sovielen Projekten ist die Wahrscheinlichkeit höher, dass z.B. eines nicht mehr weiterentwickelt wird. Gerade bei kleineren sind sich bestimmt einige unsicher. Und dann ist es auch noch schwer für die einzelnen Projekte qualifiziertes Personal zu finden, weil es einfach soviel gibt. Man kann ja nicht alles können.

D.h. für manche Unternehmen ist es daher einfacher .NET zu nehmen, weil hier gibt es nunmal ASP.NET und ADO.NET und ein Entwickler, der mit .NET Webanwendungen schreibt wird zum Großteil diese Technologien auch beherrschen.

Ich habe bereits einige Forenposts gelesen, in denen sich Entwickler dazu äußern, dass solche Aspekte vermutlich die Gründe waren, wieso die Projektleitung statt Java dann doch .NET genommen hat.

Aber mit Grasshopper läufts ja dann auch unter Linux mit Tomcat, solange Mono noch nicht so weit ist

Gruß

Mike

 

[HLX]

JSP, Struts und JSF kommen aus dem Bereich der Web-Entwicklung.

Web-Entwicklung mit Java:
--> erfolgt über Java Servlets (spezielle Klassen, die von einem Web-Container (z.B. Tomcat) verarbeitet werden); Java enthält HTML-Ausdrücke
----> JSP ist eine Weiterentwicklung von Servlets - JSP-Seiten sind keine Klassen sondern HTML-Dateien mit Java-Elementen, werden vom Web-Container zu Servlets vewandelt
-------> Struts ist ein MVC-Framework, dass auf JSP aufbaut und die Entwicklung übersichtlicher und komfortabler macht
-------> JSF ist ein Web-Oberflächen-Framework von SUN, dass ebenfalls auf JSP aufbaut. Kann mit Struts kombiniert werden

 

[Guest]

JSP ist für dynamische Webseiten, ähnlich wie PHP. Du hast ne Webseite und baust dort Java-Code ein, um dynamisch Inhalte zu erzeugen.

Jo - das habe ich soweit auch schon gesehen.

Mit JSF habe ich selbst noch nicht gearbeitet, klingt aber sehr interessant. Es erinnert stark an ASP.NET falls Du das kennst.

ASP.NET kenne ich nicht wirklich (nur vom Hörensagen). Auf jeden Klang für mich JSF auch sehr interessant, - die Frage ist/war nur ob JSF unäbhängig von JSP ist, - oder ob es eine "Erweiterung" dazu darstellt.

Hibernate ist ein Object-Relational-Mapper. D.h. angenommen Du hast eine Tabelle in der ...

Genau das stelle ich mir auch unter Hibernate vor. Also verstehe ich das richtig das Hibernate eine unabhängige Technologie ist (also unabhängig von JSP, JSF, Struts, etc.).

Was ich aber viel mehr sagen möchte: Wenn Dir Qt gefällt und Du mit Java arbeiten möchtest, ist vielleicht QtJambi was für Dich.

Danke, aber QtJambi kenne ich schon. QtJambi ist in meinen Augen auch, und ich weiß das es da viele verschiedene Meinungen gibt, ein sehr interessanter Ansatz. Allerdings kann ich bereits C++ - ich denke da ist es sinniger auch (vorerst) dabei zu bleiben. Mal sehen ob ich in Zukunft, wenn Java freie Software wird, das ändere. ;-)

Vielen Dank für deine Antworten!

MfG,
Hilefoks

P.S: Inspiriert durch einen anderen Thread hier habe ich mir das ZK-Framework einmal kurz angeschaut. Das scheint auch recht interessant zu sein - aber auch hier weiß ich wieder nicht wo ich es, im Bezug auf die anderen bereits genannten Schlagwörter, einzuordnen habe.

 

[mutex]

In "kurzen Worten aufschlüsseln" ist gut ;-)

Ich bin in dem gleichen Dilemma: Füher habe ich C/C++ gemacht, aber da das Web ja so hip ist und C++ als CGI da nicht wirklich so geeignet ist, muß ich mich die letzten Jahre auf der Arbeit mit Perl oder PHP herumschlagen ... das Scriptgefummel geht mir irre auf die Nervern und ich dachte Java könnte da ein guter Krompromiss sein, um Web-Anwendungen sauber zu Designen ... damit fing das Drama an :-/

Mein Problem sind auch die Vielzahl der "Technologien", aber insbesondere auch, daß man zu kaum einer wirklich was konkretes findet, bzw., daß mit jeder wieder ein Dutzend weitere neue Namen im Raum stehen .... und es frustriert, wenn man sich tagelang mit einer Sache herumschlägt, um dann irgendwo als Randbemerkung zu lesen, daß diese gar nicht mehr State-of-the-Art ist, sondern es da was neues, ganz anderes und viel besseres gibt.

Zu den Begriffen, die du eingeworfen hast ...

JPS ist - wie bereits gesagt wurde - sowas wie PHP ... der Vergleich ist ganz gut, denn wenn's um Webseiten geht, ist JSP sowas wie HTML, in das für die dynamischen Parts Java reingekritzelt wird. Nur ist sowas kaum wartbar und man versucht natürlich Bussines-Logik und Ausgabe zu trennen: Die Programmlogik wandert in die Servlets und man hat darin dann wieder reinen Java-Code und die JSP's übernehmen eigentlich nur noch die Darstellung. Damit rutschen die JSP's (bei sauberer Trennung) in die Rolle eines reinen Template-Systems (beim Vergleich mit PHP vielleicht sowas wie SMARTY). Um dann diese Templates auch wirklich vernünftig schreiben zu können, wurde die "JSP in XML"-Syntax eingeführt; damit die Daten auch irgendwie in das Template kommen, gibt's die JSP-EL und damit man die Templates vernünftig erweitern kann, kann man eigene Taglibs schreiben und da manche Tags allgemein und oft gebraucht werden gibt's die JSTL .... das nimmt kein Ende - ich sag ja, da wird man kirre bei.

Jedenfalls müssen die Daten, die man im Servlet generiert, irgendwie von selbigen in die JSP-Seite kommen, damit letztere sie darstellen kann. Hier kommen die Java-Beans ins Spiel: Ursprünglich waren diese mal gedacht, um Eigenschaften einer visuellen Komponente zu beschreiben, um dann damit sowas wie diese Klickibunti-Windows-ActiveX-GUI-Builder aufbauen zu können. Im Rahmen von Web-Applications werden sie nun aber eigentlich nur noch verwendet, um eben "Eigenschaften", also Daten zu halten. Und so kann also z.B. ein Servlet eine Bean erzeugen, diese mit Daten befüllen und die JSP nimmt sich die Daten aus der Bean wieder raus. Dabei wird hier auch nur mit Wasser gekocht: Meißt schreibt man einfach nur eine Klasse mit ein paar Gettern und Settern für die Daten und fertig ist die Bean.

Gut, jetzt haben wir: Servlets (die Programmlogik), Beans (die Daten) und JSP (die Darstellung) und finden uns also plötzlich mitten im guten alten MVC-Pattern (aka Model2) wieder. Für das Zusammenspiel von Controllern (Servlets), mit den Modellen (Beans) und den Views (JSP) muß man sich in seinem Projekt ein Framework basteln - oder eben Struts benutzen. Zumindest habe ich's so verstanden, daß Struts ein MVC-Framework für Java-WebApps ist. Nur waren viele der oben beschriebenen Konzepte ursprünglich die eigentliche Aufgabe von Struts, aber einiges findet sich eben mitlerweile in den aktuellen Java-Standards direkt wieder (bleibt die Frage, ob und wofür man Struts braucht). Und wenn man für die aktuellen Techniken auf ein Framework zurückgreifen will, dann stellt sich die Frage, ob man nicht vielleicht doch eher Spring in betracht ziehen sollte. Wobei aber auch die Standards nicht unbedingt das Mittel der Wahl sein müssen, weil man statt JSP dann doch auch Tapestry nehmen könnte und im Zusammenhang mit JSF eigentlich eh überall angeraten wird, für diese Facelets anstatt JSP's zu benutzen ... ich sag ja: es nimmt kein Ende und ich hab das ganze Zeug auch noch nicht kapiert

Naja, aber mit den Beans könnte man zu Hibenate kommen: Wie bereits erläutert wurde handelt es sich dabei um ein ORM-Framework - hierbei geht's grob gesagt darum, die unteschiedlichen Welten von objektorientierter Programmierung und relationaler Datenbankmodellierung miteinander zu verheiraten. Und da die Daten irgendwo herkommen müssen und irgendwo hin müssen stößt man in Sachen Java WebApps früher oder später auf Hybernate. Hat man sich damit angefreundet, stellt man schnell fest, daß sowas eine sehr feine Sache ist - und stellt dann fest, daß es mitlerweile eine Java Persistenz API gibt. Letztere ist ein entsprechender Standard, der insbesondere bei EJB's zum Einsatz kommt. Eigentlich ist diese API eben nur eine API und also nur eine andere Sichtweise auf das ORM - so verwendet z.B. JBoss Hibenate um die Persistence API zu realisieren. Naja, damit kommt man dann von seinen einfachen Beans zu den Enterprise Beans, die dann ab der 3.0 Version quasi auch nur POJOs sind, die ausgiebig gebrauch von den Java 5 Annotations machen. Nebenbei hat die Persistence-API dann noch ihre eigene Query-Language ... aber man merkt, daß man bei ernsthafteren Anwendugen kaum um die EJB's drum herum kommt und mit diesen ist man schon mal gut Beschäftigt ... und handelt sich werweißwas an neuen Begriffen und Techniken damit ein.

Hm, jetzt habe ich die JSF vergessen, mit denen man dann bei Facelets, Tobago, MyFaces und sonstwas landet, um dann festzustellen, daß die aktuelle Spezifikation vom Tomcat noch gar nicht unterstützt wird. Womit wir bei Tomcat dann bei der Frage wären, was man denn überhaupt braucht: Tomcat, JBoss, Glassfish? Und haben wir dann die Apllication-Server, dann schlägt man sich mit dem Thema Deployment rum, kommt zu Ant, findet dann noch XDoclet, merkt dann, daß letzteres Java 1.5 nicht unterstützt und Annotations ja eigentlich doch besser wären, hat dann aber keine praktische Umsetzung zum Bespiel zur erzeugung von Taglib-Deskriptoren aus Annotations per Ant an der Hand und merkt, daß das WTP PlugIn für Eclipse entweder XDoclet oder eben gar nichts zu machen scheint ... undundund


Ich denke, daß wichtigste sind hier gute Bücher - aber welche?!? - brauchbare Resourcen im Netz habe ich kaum gefunden (habe mich nun Tagelang durch veraltete Artikel zu überholten Techniken und hochgelobte Frameworks ohne irgendeine Doku gequält). In Sachen Java Programmierung an sich (und die braucht man halt als Grundlage) finde ich die Core Java Bände 1 und 2 gut - da steht eigentlich immer irgendwo drin was man braucht (es gibt meiner Ansicht nach irre viele Blabla-Javabücher). Auf TheServerSide.com gibt's ein Buch "Servlets and JavaServerPages" kostenlos zum Download - ist recht veraltet, hat mir aber geholfen ein bißchen ein Gefühl dafür zu bekommen, was das ganze denn überhaupt sein soll (leider scheint es keine aktualisierte Auflage zu geben). Ich habe mir jetzt auch noch so 'nen oReiley-Wälzer zu EJB3.0 angetan ... naja, ich kriege immer den Tipp "hol dir ein gutes Buch" ... aber mal ehrlich: Wenn man sich mal anguckt, wieviele tausend Seiten man mit den Büchern zusammen hat, die ich grade erwähnt habe - das ist einfach nicht praktikabel, wenn man das beruflich einsetzen will ... wer kennt dieses Buch, daß einem da weiter hilft?!?

Alles in allem: Ich würde da auch gerne mal langsam einen Überblick bekommen und bin da genau so dankbar für alle Kurzerläuterungen, Hinweise, Links, Buchtipps, etc. ... vielleicht gibt da dieser Thread im weiteren Verlauf noch was her?!?


In diesem Sinne ...
bis denne

 

[miketech]

Hi mutex,

ein ausgezeichneter Beitrag Er spiegelt genau meine Erfahrung wider, die ich in den letzten paar Wochen gemacht habe, in denen ich nun versuche einen Durchblick zu bekommen. Und das ist nicht der erste Versuch, vor einem Jahr habe ich es schonmal versucht, hab aber dann irgendwann die Lust an der Sache verloren. Und wenn man dann sieht, wie schnell man mit z.B. Ruby On Rails, oder ASP.NET seine Webanwendung fertig hat, die man geplant hat ist es einfach nicht ganz praktikabel.


Vor einem Jahr habe ich mal mit dem Buch J2EE von Thomas Stark angefangen. Es erklärt sehr ausführlich einzelne Aspekte von J2EE, etwas zu ausführlich für meinen Geschmack. Ich fand das zwar alles interessant, aber nach ein paar Tagen hatte ich auf J2EE erstmal keine Lust mehr


Ansonsten habe ich vor Kurzem (zweiter Versuch mit JEE) das Buch "JBoss at Work" gelesen von Tom Marrs und Scott Davis (jbossatwork.com). Das Buch fand ich sehr gut. Es ist nicht sonderlich dick (ca. 250 Seiten) und geht die Themen JSP, Servlets, JDBC, Hibernate, EJB, Webservice der Reihe nach durch. Das ganze wird anhand eines durchgehenden Beispiels erläutert. D.h. es fängt an mit einer einfachen statischen HTML Seite, dann JSP, dann kommt die Logik ins Servlet, dann kommen die Daten in die Datenbank (JDBC) usw.

Es wird also jedes mal deutlich, wofür nun die neue Technologie dazu kam. Das ganze wird natürlich auch regelmäßig deployed mit Ant und XDoclet usw. Das wird aber immer recht schnell abgehakt. Das Buch arbeitet aber noch mit EJBs 2.x. Das Kapitel Webservices war leider auch etwas frustrierend. Es ging Seiten lang und hat erklärt, wie man genau was machen muss, wie die Objekte serialisiert werden usw. Alles sehr spannend, keine Frage. Aber da ich eben bißchen mit ASP.NET rumgespielt habe vergleiche ich das natürlich immer sofort. Und ein Webservice in ASP.NET ist eine Sache von < 1 Min. Aber hier muss man eben sagen: Was im Hintergrund passiert ist die eine Sache. Was die IDE mir aber an Tools zur Verfügung stellt eine andere. Ob sich seit dem Buch da etwas geändert hat weiß ich natürlich nicht.

Ansonsten geht das Buch noch auf die Themen Sicherheit, JMS und JavaMail ein. Das hab ich aber übersprungen.


Da JSF nun start in die Richtung von ASP.NET geht und ich davon recht begeistert bin habe ich noch ein paar Bücher hierzu bestellt (ausgeliehen). Will das ja nicht alles kaufen Also wenn ich damit durch bin kann ich vielleicht etwas mehr zu JSF sagen.


Ein anderes Problem ist ja, dass man nun nicht einfach wie in ASP.NET loslegen kann, weil man in einer GUI nur was zurechtklicken und auf "Play" klicken muss. Die Webtools in Eclipse sind noch nicht sonderlich ausgereift und man muss schon sehr genau wissen, was man da programmiert. In Netbeans geht das derzeit etwas besser von der Hand, aber auch hier nützt das alles nichts, wenn man nicht vorher weiß, was man da macht. ASP.NET kann man mit ein paar Klicks, Learning by doing irgendwie hinbekommen. Bei Ruby On Rails ist es ähnlich, dass man in wenigen Minuten mit einem Howto seine erste Anwendung fertig hat, weil man im Grunde das ganze Gerüst nur 1 zu 1 kopieren muss. Keine Deployment Deskriptoren und weiß der Geier Aber dafür bietet JEE eine enorme Flexibilität und seitdem ich das Buch gelesen habe (innerhalb von 3 Tagen fast komplett eingesaugt) bin ich davon ziemlich fasziniert.


Wofür nun diese ganzen Frameworks, wie Spring und Struts usw. sind kann ich nicht ganz beurteilen. Struts scheint ja nun nicht mehr ganz so "in" zu sein und Spring steht wohl auch im Gegensatz zu EJB 3. Also nun mal abgesehen davon, dass man in JEE viel mit Ant und Deployments zu kämpfen hat fand ich die Beispiele im Buch nicht kompliziert. Weiß nicht, was mir ein Framework hier an Arbeit abnehmen soll.



Das Problem ist nun, dass man eben nicht einfach mal anfangen kann, wenn man nichtmal weiß, wofür das alles überhaupt ist, was es so gibt. Und ich kenne bisher kein Buch, welches mal kurz erklärt, was das alles soll und wofür das ist. JBoss At work hat ja nur ein paar einzelne Teile angesprochen. D.h. man ist natürlich vielleicht nach einem Buch wie JBoss At Work in der Lage eine Webanwendung zu gestalten. Aber immer, wenn man etwas umsetzt wird man es mit den Mitteln umsetzen, die man eben kennt. Z.B. wäre ich nie auf die Idee gekommen Hibernate einzusetzen, ging ja auch so. Ich kenne zwar ORM vom Prinzip her, habe es aber nie eingesetzt. Da ist es eben wichtig, dass man das mal gesehen hat. Und so ist es eben bei vielen dieser ganzen Technologien: Man bekommt sicher vieles mit ein paar Mitteln umgesetzt, aber vielleicht geht es anders leichter?


Nun, was ich so gehört habe ist es wohl so, dass man ja nicht alles davon wirklich beherrschen kann. Es ist auch immer fraglich, ob sich der Aufwand lohnt, das ist so mein Problem an der Sache.

Daher bleibt aber wohl nichts anderes übrig als mit den paar Mitteln die man hat einfach mal anzufangen. Im Grunde benötigt man ja nicht viel für eine einfache Webanwendung. JSPs reichen ja Aber setzt man noch Servlets, Hibernate usw. ein wird es vielleicht komfortabler und man merkt, wofür man die Dinger braucht. Und dann kann man sich überlegen, was man nun als nächstes einsetzt. Am Ende wird man nicht sagen können, dass man den ganzen Rattenschwanz an Frameworks JABC bis JXYZ beherrscht. Sondern man kann nur sagen: Ich verwende für JEE Anwendungen JSP + JSF + JDBC + Hibernate + EJB + sonst was.

Und hier sind wir wieder beim Problem von vorhin: Ich weiß nicht, was "sonst was" noch alles sein könnte. Vielleicht gibts das ja wieder was ganz tolles, was man noch einsetzen könnte, man kennt es aber nicht.


Also wer die Wahl hat, hat die Qual


Gruß

Mike

 

[mutex]

Daher bleibt aber wohl nichts anderes übrig als mit den paar Mitteln die man hat einfach mal anzufangen.

Ja, den Ansatz versuche ich auch zu verfolgen: Man weiß (hoffentlich), was man machen will und weiß aus anderen Umgebungen, was man wohl so ungefähr dafür braucht ... denkt man :-(

Dann versucht man mal einen ganz simplen Web-Service zu realisieren ... Java+SOAP in Google eingegeben führt einen zu Apache SOAP ... hört sich gut an ... man ließt sich ein ... und irgendwo heißt's dann, daß es da ja den Nachfolger Apache AXIS gibt ... also ließt man sich da ein ... und dann sind die Webservices in EJB3 per @WebService doch viel einfach ... undsoweiterundsoweiter. Irgendwann bricht man das ganze ab und sagt sich: "So, ich nehm jetzt einfach das, egal, ob das veraltet oder zu umständlich ist" und merkt man, daß die IDE oder der Container dies oder das nicht unterstützt und ist dann Stunden damit beschäftigt hier herumzukonfigurieren und dort irgendwelche Dokus zu suchen.

Was man doch zu diesen ganzen Themen bräuchte wäre eine Kurzbeschreibung, wofür's da ist; vielleicht der ein oder andere Code-Schnippsel, den man als Ausgangspunkt für eigene Experimente verwenden kann und ein paar Hinweise, wie man's in dieser IDE oder mit jenem Build-File auf dem einen oder anderen Container ans Laufen kriegt.

Findet man sowas nicht irgendwo? Zu vielen Libs findet man eine Intro-Seite, wie toll das ganze ist und dann hunderte Seiten API-Docs ... und dann ist's doch längst veraltet oder aber doch noch zu neu. Gibt's vielleicht ein Java-WebApp-Wiki oder sowas?!?

 

[Guest]

Ihr dürft mal eines nicht vergessen, J2EE ist nix für kleine Popelprojekte, das ist für High End Lösungen gedacht.
Mit PHP, Ruby oder ASP.Net hast du schnell eine laufende Webanwendung hingefrickelt aber das kann ich mit JSP und JSTL auch und wenn ich etwas Ahnung habe mache ich das mit JSF auch ziemlich schnell. Ihr solltet euch nicht mit EJB und so Sachen beschäftigen wenn ihr garnicht wisst was ihr eigentlich wollt.

Zusammenfassend kann ich euch folgendes für eine mittlere bis große Webanwendung empfehlen:

Tomcat
JSF (myfaces und facelets)
Hibernate

Genau diese Kombination habe ich gerade durch und bin sehr zufrieden. Daneben kam noch Spring zum Einsatz und für Wizards habe ich dann noch Spring Webflow verwendet, was ich shr gut finde.

 

[Gast]

mysql, Ant und Eclipse (mit Exadel wegen der Faceletsunterstützung) waren auch noch dabei.

 

[bronks]

m.E. gehen viele Leute da etwas verkehrt ran. Stand der Dinge ist momentan J2EE und daran wird sich jahrelang nichts ändern. Wenn man ins Thema reinkommen mag sollte man sich den J2EE Patternkatalog reinziehen und schrittweise eine einfache App, aber als strenge BluePrint-Lösung nach Spec, entwickeln ohne irgendwelche Frameworks zu verwenden.

Link zum Patternkatalog: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

 

[miketech]

Hi,

d.h. bronks Du räts von Sprung und Co für den Anfang eher ab?

@Gast:
Das Problem ist: Ich mach es z.B. so, dass ich grundsätzlich versuche alles damit umzusetzen, was ich bis zu diesem Zeitpunkt kann. D.h. ich würde nun auch eine große Business-Anwendung mit PHP aufziehen. Es ist also schwer zu sagen: Man soll J2EE und EJBs nur verwenden, wenn man weißt, was man da tut, bzw. wofür das ist. Ich werds aber doch nie benutzen, wenn ich nie weiß, was das überhaupt ist Ist son bißchen ein Henne Ei Problem.

D.h. man bräuchte sonst jemanden der sagt: Hey, das machst Du alles total falsch, dafür solltest Du J2EE nehmen. So jemanden trifft man aber nicht täglich.

Es ist also daher schon wichtig, dass man irgendwie erstmal einen Einstieg findet und dann kann man abwägen: Brauch ich das überhaupt?

Für kleine Projekte reichen sicher JSP, JSF usw. Aber sobald man noch einen Webservice dazupacken will wirds ja schon, wie von mutex beschrieben eine ganze Ecke komplexer. Ob das mit EJBs nun besser funktioniert weiß ich nicht.

Gruß

Mike


Edit:

@mutex: Es gibt ja z.B. auf Wikipedia immer kurze Erklärungen. Das Problem ist: Wenn man gar keine Ahnung hat und keine Vorstellung bringen diese kurzen Erklärungen immer recht wenig. Also ich persönlich kann mir unter den Erklärungen immer sehr wenig vorstellen. Erst wenn ich das in der Praxis gesehen habe und vielleicht auch mal selbst verwendet habe ist es mir wirklich klar. Vielleicht waren die bisherigen Erklärungen auch einfach zu kompliziert gehalten. Vielleicht gibts aber ja wirklich ein Buch welches alles mal anspricht.


Wie wärs denn zum Beispiel hiermit:

http://www.amazon.de/J2EE-Java-komp...ef=sr_1_2/303-7163804-6196206?ie=UTF8&s=books

 

[mutex]

Ihr dürft mal eines nicht vergessen, J2EE ist nix für kleine Popelprojekte, das ist für High End Lösungen gedacht.

Ich denke, darum geht's auch gar nicht unbedingt (und deswegen sind wir da vielleicht im falschen Forum gelandet), aber im Endeffekt sind die Übergänge zur EE fließend (und also sind wir vielleicht doch nicht so ganz im falschen Forum). Man weiß ja eben nicht, auf welcher Ebene man sich bewegt und worauf man sich beschränken sollte, wenn man nicht den groben Überblick bekommt (und darum ging's ja hier ursprünglich).

Es gibt ja z.B. auf Wikipedia immer kurze Erklärungen.

Und eigentlich sucht der Einsteiger doch genau sowas: Bei dem ein oder anderen Artikel dort hat man ja den Aha-Effekt "gut, jetzt weiß ich so ungefähr was das ist". Aber dann fehlt eben doch oft der erste Einstieg oder Code-Schnippsel, eben das "okay, wo fange ich an". Deswegen meine Frage, ob's nicht irgend ein gutes Wiki speziell zum Thema Java Web-Applications gibt.

 

[HLX]

Struts und JSF sind Frameworks. Frameworks sind keine losgelösten Technologien, sondern Hilfestellungen für die Verwendung einer Technologie, die auf dieser aufbauen. Man kann sich Frameworks auch selber basteln, wenn man feststellt, das einen die von der Technologie zur Verfügung gestellten Mittel nicht ausreichen - aber einfacher ist es natürlich ein Vorhandenes, Ausgereiftes zu Verwenden.

Struts und JSF sind keine Fremdkörper sondern im Prinzip einfach nur eine Sammlung von Klassen, Servlets, XML-Dateien, die einen dabei helfen schönere, einfacher wartbare und übersichtlichere Web-Anwendungen zu schreiben.

Versucht also mal mit den Mitteln von JSP mit JSTL eine RICHTIGE MVC-Anwendung zu bauen. Das geht, ist aber kompliziert. Mit Struts wird dies eben genau vereinfacht. Es erweitert die Servlet-Technologie entsprechend. Allerdings: Wer nur 2 JSP-Seiten entwickeln will, davon 1 Formular und eine Ausgabeseite - Anwendung inkl. Datenbankabfrage, der braucht gar kein Framework, weil es mal eben so hingekritzelt werden kann und deswegen weder unübersichtlich ist noch einen großen Wartungsaufwand darstellt.


Nun noch ein paar Anmerkungen zu den bisher gefallenen Begriffen:

Manchmal habe ich den Eindruck, dass MVC nicht richtig verstanden wird. Die Programmlogik gehört NICHT ins Servlet. Ein Servlet ist eine Kommunikationsschnittstelle zwischen Anwendung und Server. Ein Controller dient lediglich zur Anwendungskontrolle, sprich: setzen von Zuständen im Model und Auswahl der View. Die Anwendungslogik wird übrigens dem Model zugeordnet.

JavaBeans: sind immer eine Klasse mit gettern und settern. Es gibt klare Regeln zum Aufbau einer JavaBeans, sonst würden sie auch nicht funktionieren.

Abschließend:
Wenn man sich in das Thema Webanwendungen mit Java einarbeiten will, ist folgende Reihenfolge sinnvoll (Java-Kenntnisse vorausgesetzt!). Wenn man eines verstanden hat, dann das nächste:

1. Webtechnologie allgemein (HTTP / HTML / XML / Webserver)
2. Webtechnologie Java (Servlet-Engine, Application Server / dann erst Servlets, dann JSP)
3. MVC-Entwurfsmuster und JavaBeans
4. Web-Frameworks (Struts / JSF / Cocoon etc.)

Danach kann man sich mit der Model-Komponente herumschlagen. Hierunter fällt u.a. EJB und Hibernate.

Zu jedem Thema sollte man mal eine Beispielimplementierung gemacht haben um es richtig verstanden zu haben. Danach ist man fit! :wink:

 

[robertpic71]

Jetzt möchte ich auch noch meinen Senf dazugeben. Ich stecke zwar erst in meinem ersten Webprojekt (ZK), aber das durchstöbern von verschiedenen Frameworks kenne ich nur zu gut.

m.E. gehen viele Leute da etwas verkehrt ran. Stand der Dinge ist momentan J2EE und daran wird sich jahrelang nichts ändern....sollte man sich den J2EE Patternkatalog reinziehen

Obwohl kein J2EE-Profi bin, kann ich das nicht gut heißen. Der Anteil der Lightweight-Lösungen nimmt stark zu. Selbst Java-Promoter IBM hat auch PHP als "Programmiersprache" aufgenommen.

Ich kann die schlechte Presse für J2EE zum Teil nachvollziehen:

Businessweek
Ein-Bunt-und-Klick-Tool (Lansa, aber auf DOT.NET vs. Java achten!)

mMn sollte man sich das "Monster J2EE", so gut es geht ersparen - vor allem wenn man noch nicht damit vertraut ist. Bis man sich da eingearbeitet hat, ist man mit anderen Lösungswegen dem Ziel wohl schon sehr nahe...

Es mag schon sein, dass man ab einer gewissen Größenordnung nicht darum herumkommt (z.B. wenn die Persistenzschicht auf verschiedene Datenbanken verteilt ist und man sich sicher sein muss, dass ein COMMIT nur dann geht, wenn es sicher überall geht). Wenn man Load-Balancing zwischen von mehreren Applicationservern braucht, tut's der Tomcat auch nicht mehr (laut Hilfe, kann Tomcat nur nach einfachen Regeln aufteilen - kann ja noch werden).

ABER alles darunter --> Finger weg und kleinere Brötchen backen

Bevor das hier in ein Anti-J2EE und Pro .NET Posting übergeht:
Man kommt mit .NET & Co. (lernen inklusive) sicher schneller ans Ziel als mit J2EE.

ABER: Mit MS fängt man sich ja auch allerlei Problemchen ein. Das wichtigste: Laut einer Studie (in der Computerwelt abgedruckt) ist bei den MS-Entwicklungstools mit jeder Version 50% des Codes zu warten, bei Java nur 20%.

Die Zahlen finde ich zwar ein wenig "krass", aber wer schon mal mit MS-Tools entwickelt hat, kann davon sicher ein Lied singen (z.B. geänderte Defaultwerte in der API nach Servicepack...). Manches läuft einfach aus (VB6 und ASP) und für den Nachfolger (VB.NET, ASP.NET) muss man dann doch an die Sourcen.

Hier noch meine Eindrücke zu den gesichteten Lösungen/Frameworks:

Hibernate
Hibernate wurde ja schon angesprochen. Aber es macht nicht nur das Mapping, sondern entkoppelt auch von der Datenbank. Dank eigener Abfragesprache (SQL like)muss man sich nicht mit den verschiedenen SQL-Dialekten herumschlagen(*), sondern Hibernate. Auch unterschiedliche Speicherformate für Dateninhalte (z.B. BLOB's, CLOB's..) gleicht Hibernate aus.

(*) Wenn man Direktabfrage durchschleußt, ist DB-Unabhängigkeit wieder in der Hand des Entwicklers.

Servlet
Auch wenn man keine Web-Anwendungen so schreiben sollte, ist das Verstehen der Servlet's absolute Pflicht für Java-Webentwicklung.

JSP
Mit Tag's ist die Entwicklung schon etwas erträglicher. Bei JSP sieht man erstmalig, wie einem JavaBeans Arbeit abnehmen können (gleichnamige Formularfelder können automatisch im Bean übernommen (setXxxxx) werden).

Struts
Ich habe zwar noch kein "schöne" Strutsanwendung gesehen, aber bei den angebotenen Lösungen musste ich mich wenigstens nicht fragen "Wozu brauche ich das?". Beispiel: Fehlermeldungen an die html-Seite schicken. Eine einfache Fehlermeldung (aus dem Model) auszugeben kann, bei einer MVC2-Applikation schon kompliziert werden.

--> nicht ganz schlecht, aber eine klassiche Webappl. ist nicht mein Ziel

Spring
Lösungen für Probleme die ich noch nicht habe....
Dependency Injection in einfachen Worten
Das Problem: Ich brauche ein Objekt der Klasse C. Diese ist abhängig von Klasse B und diese wiederum von Klasse A.
Die Lösung: Um aus abhängigen Klassen wieder einfache Klassen (wie POJO's) zu machen, werden die Abhängigkeiten in einer XML-Datei hinterlegt. Damit kann ich das fertige Objekt der Klasse C anfordern. Das Framework erledigt den Rest.

Aspektorientierte Programmierung stark vereinfacht
Gleichartige Arbeit (z.B. Logging, Securtycheck) = Aspekte werden ausgelagert und zu eigenen Klassen abgehandelt.

JSF & Co
Da ich eine Nachfolgeplattform für eine reine Textanwendung (IBM AS/400 alias i5 alias iSeries) kommt für mich/uns eine klassiche Weboberfläche nicht in Frage. Der Grund dafür sind zahlreiche tastaturintensive Anwendungen wie z.B. der Telefonverkauf. Bei uns fällt die Auswahl eher zwischen SWT & Swing & Ajax-Web.

ZK - Ajax without Javascript
Aufgrund der gewünschten Tastaturbedienbarkeit, schien eine Weblösung schon außer Sicht. Aber Dank AJAX können sogar Funktionstaten und STRG/ALT Kürzel in der Webapplikation abgefragt werden. Auch die mitgelieferten Widgets sind gut mit der Tastatur bedienbar.

Aber das Wichtigste: Die Entwicklung mit ZK ähnelt doch der Desktopentwicklung. D.h. ich kann einem Button eine Javaklasse/Methode zuordnen und diese Methode kann noch Änderungen an der Seite vornehmen, ohne eine neue Seite aufbauen zu müssen. Hier ist man dem Desktop-MVC schon wieder recht nahe.

ZK erfordert nicht zwingend ein weiteres Framework - ist aber mit vielen (Hibernate, Spring, Struts..) kombinierbar. Für Ausführung reicht ein Webcontainer/Tomcat.

 

[bronks]

... Ich kann die schlechte Presse für J2EE zum Teil nachvollziehen:

Businessweek
Ein-Bunt-und-Klick-Tool (Lansa, aber auf DOT.NET vs. Java achten!)

mMn sollte man sich das "Monster J2EE", so gut es geht ersparen - vor allem wenn man noch nicht damit vertraut ist. Bis man sich da eingearbeitet hat, ist man mit anderen Lösungswegen dem Ziel wohl schon sehr nahe...

Zu Link Nr. 2: Ganz unten auf der Seite steht, daß die Anzahl der Arbeitstage mit einem Dreisatz aufgrund der Zeilenanzahl im Code berechnet wurde. So einen Mist kann ich nur als peinlich bezeichnen.

Blöd ist, daß die WebAPI zu EE gehört. So kommt es immer wieder zu Mißverständnissen.

 

[miketech]

Servus zusammen,

bleiben wir mal bei einem einfachen Beispiel:

Eine simple Webanwendung, jedoch mit Transaktionen und Webservices.

Das kann ich ja nun beliebig groß aufziehen. Mir fällt es einfach schwer zu beurteilen, wie weit ich gehen soll. Zunächst würde ich gerne mit JSF arbeiten, sieht für mich sehr vernünftig aus

Wie eben gesagt wurde gehört die Anwendungslogik wohl aber nicht ins Servlet, ok.

Dann kommen wir sehr schnell zu EJBs, oder? Irgendwo muss die Anwendungslogik ja hin. Bin ich dann automatisch bei einem Application Server wie JBoss?

Und mache ich das nun z.B. per Hand, oder nehme ich für sowas Struts, oder Spring? Ich weiß einfach nicht, ob mir so ein Framework persönlich was bringt und wo es überhaupt was erleichtert.

Vielleicht ist Java auch für solch eine kleine Anforderung (Webanwendung) einfach zu hoch gegriffen? Sollte ich Java lieber den Vorrang geben, wenn es sich um wirklich komplexe Anwendungen handelt und sowas kleineres lieber mit Ruby on Rails machen?


Gruß

Mike

 

[HLX]

Wie eben gesagt wurde gehört die Anwendungslogik wohl aber nicht ins Servlet, ok.

Dann kommen wir sehr schnell zu EJBs, oder? Irgendwo muss die Anwendungslogik ja hin. Bin ich dann automatisch bei einem Application Server wie JBoss?

Die Anwendungslogik gehört ins Backend. Dieses kann mit EJBs aber auch mit einfachen Klassen realisiert werden. Wenn die BL im Backend liegt ist sie unabhängig von Ihrem Verwender. Es muss ja nicht immer ein Servlet sein, dass z.B. eine Kalkulation in der BL-Komponente anstößt. Wenn man die Anwendung Standalone betreiben möchte, dann ist es schlecht, wenn sämtliche Berechnungen und Vorgänge im HTTPServlet stehen.

Also: im Sinne von MVC sollte über ein Formular ein Servlet aufgerufen werden. Dieses kann dann einen Vorgang im Backend anstoßen, dessen Ergebnis dazu ausreichen sollte vorhandene Beans zu befüllen, nötige Attribute zu setzen und eine Ausgabeseite zu bestimmen. Exceptions können z.B. auch im Servlet abgefangen werden und die Ausgabe z.B. auf eine Fehlerseite leiten.

 

[bronks]

... Dann kommen wir sehr schnell zu EJBs, oder? Irgendwo muss die Anwendungslogik ja hin. Bin ich dann automatisch bei einem Application Server wie JBoss? ...

Anstatt dauernd total planlos irgendwelche Vermutungen anzustellen, wäre es nicht verkehrt sich die Beschreibungen zu den Patterns aus dem von mir oben geposteten Patternkatalog durchzulesen. Zu jedem Pattern steht drin, welche Techniken man wie verwenden kann. Das ganze was in dem Diagramm dargestellt ist kann man ganz ohne EJB anwenden.

Robertpic71 hat oben einen Link zu dem KunterBuntKlickTool gepostet in dem behauptet wird, daß es 120 Tage dauert, den PetShop in Java zu proggen. Ich habe mir gestern den PetShop für EJB3 runtergeladen. Da soll mir mal jemand zeigen wie man kleine Brötchen noch kleiner backen kann.

 

[Guest]

Struts
Ich habe zwar noch kein "schöne" Strutsanwendung gesehen...

Schau dir doch z.B. mal http://www.dialo.de/ oder http://sz-mediathek.sueddeutsche.de nur zwei schöne "Strutsanwendungen".

Ich denke, dass du garnicht verstanden hast was struts eigentlich ist, da kannst du genau so gut Ajax und co einsetzen.

 

[robertpic71]

Struts
Ich habe zwar noch keine "schöne" Strutsanwendung gesehen...

Schau dir doch z.B. mal http://www.dialo.de/ oder http://sz-mediathek.sueddeutsche.de nur zwei schöne "Strutsanwendungen".

Steht ja nicht dabei, wieviel ich gesucht habe... :wink: Aber ich muss zugeben, dass ich da von 3 (eine läuft bei uns im Haus) Anwendungen auf die Struts-Familie geschlossen habe.

Ich denke, dass du garnicht verstanden hast was struts eigentlich ist, da kannst du genau so gut Ajax und co einsetzen.

Ajax fließt ja mittlerweile in fast jedes Web-Framework ein. Aber mir geht es nicht primär um die Optik, sondern 1. um die Tastaturbedienbarkeit (die bekomme ich bei struts nur wenn ich selber javascript einbette - korrigiere mich wenn ich da falsch liege) und 2. einer intuitiven Entwicklung der Anwendung, welche Desktopentwicklern und Quereinsteigern entgegekommt. ZK ist hier eine Möglichkeit - weitere wie z.B. RAP (von den RCP-Entwicklern) werden noch folgen.

Robertpic71 hat oben einen Link zu dem KunterBuntKlickTool gepostet in dem behauptet wird, daß es 120 Tage dauert, den PetShop in Java zu proggen. Ich habe mir gestern den PetShop für EJB3 runtergeladen. Da soll mir mal jemand zeigen wie man kleine Brötchen noch kleiner backen kann.

>> Dieser Thread << (von dir gestartet) hat mich in meiner Anti-EJB-Haltung bestärkt.

Daher meine Frage: Wird man mit der Zeit (nach dem Einarbeiten) doch zum EJB-Fan oder ist EJB3 soviel besser?

Noch zum KunterBuntKlickTool: Ich wollte hier nur mal zeigen, womit die Entscheidungsträger so konfrontiert werden. Das sich bei den Jubelbroschüren öfters die Balken biegen, ist ja auch nichts Neues.....

 

[bronks]

...

Robertpic71 hat oben einen Link zu dem KunterBuntKlickTool gepostet in dem behauptet wird, daß es 120 Tage dauert, den PetShop in Java zu proggen. Ich habe mir gestern den PetShop für EJB3 runtergeladen. Da soll mir mal jemand zeigen wie man kleine Brötchen noch kleiner backen kann.

>> Dieser Thread << (von dir gestartet) hat mich in meiner Anti-EJB-Haltung bestärkt.

Ja da war ich echt angearscht, als ich herausgefunden habe, daß meine App auf anderen AS nur zur hälfte läuft und jeder AS seine eigenen Descriptoren hat, welche man per Hand kaum anpassen kann ohne dabei etwas zu zerschiessen. Mittlerweile habe ich mich damit abgefunden, da nicht jeder AS ein Abklatsch des Referenz AS von Sun ist. Hinter jedem bedeutenden AS steckt eine andere, neue und beeindruckende Technik dahinter, welche ihre ganz besonderen Anwendungsmöglichkeiten bietet. Kurz gesagt: Man proggt eine App für einen AS in JAVA. Platformunabhängigkeit gibt es da nur vom Betriebssystem.

Daher meine Frage: Wird man mit der Zeit (nach dem Einarbeiten) doch zum EJB-Fan oder ist EJB3 soviel besser?

Die EJBler sind und bleiben die großen Macher. Sich in das Thema einzuarbeiten ist mühsam, weil man von vornherein sehr viele Sachen wissen und können muß. z.B. JNDI, RMI, Packaging und die Codegeneratoren. Wenn man die Einarbeitung hinter sich und das Thema im Griff hat, dann nimmt man EJB, weil man damit schneller sein wird und das ganze nicht so fehleranfällig ist, als wie wenn man alles per Hand ausprogrammieren würde. Man erzeugt zwar extrem viel Code und unübersichtliche XmlDateien, aber das macht zum Großteil ein Generator.

Bei Verwendung als Persistenzmaschine hat EJB im Vergleich zu z.B. Hibernate und anderen DbMappern den Vorteil, daß EJB nur eine Spezifikation für eine API ist und es dem Hersteller der AS überlassen bleibt, was im Hintergrund passiert. So gibt es AS, die für eine gestestete Transaktion 5 Sekunden brauchen und ein anderer AS nur 0,5 Sekunden. Bei WebApps gerät man höchstwahrscheinlich nie in Zeitnot, aber dann gibt es noch genau die Anwendungen für welche JEE geschaffen wurde.

Noch zum KunterBuntKlickTool: Ich wollte hier nur mal zeigen, womit die Entscheidungsträger so konfrontiert werden. Das sich bei den Jubelbroschüren öfters die Balken biegen, ist ja auch nichts Neues.....

Ich hab ja nur meinen Spaß an dem Mißt, der auf der Werbeseite geschrieben ist.

 

[Gast]

Dieses ZK-Framework verwendet doch Javascript, steht ja auch in den FAQs. Hätte mich auch gewundert wie das im IE ohne JS laufen sollte.

 

[LordSam]

m.E. gehen viele Leute da etwas verkehrt ran. Stand der Dinge ist momentan J2EE und daran wird sich jahrelang nichts ändern. Wenn man ins Thema reinkommen mag sollte man sich den J2EE Patternkatalog reinziehen und schrittweise eine einfache App, aber als strenge BluePrint-Lösung nach Spec, entwickeln ohne irgendwelche Frameworks zu verwenden.

Dabei übersiehst du, das J2EE auch nur ein Framework ist. Und wie bei jedem guten Framework, obliegt es dem Anwender (also in dem Fall dem Entwickler) welche Funktionen er daraus verwenden will - und welche nicht. Wer mit Servlets und JSPs gut leben kann, aber keine EJBs für die Objektpersistenz verwenden will nimmt eben etwas anderes, z.B. Hibernate.

Die in den Core J2EE Patterns beschriebenen Design Patterns sind auch nicht darauf hin ausgelegt das sie nur mit J2EE Bordmitteln verwendet werden können. Im Gegenteil - diese Patterns sind zum Teil ganz allgemeingültig spezifiziert und z.T. älter als J2EE selbst. Deshalb ist es durchaus empfehlenswert sich das ein oder andere Pattern genau durchzulesen und auszuprobieren, wenn man sich erstmal ein wenig eingearbeitet hat.

Wobei es mir aber nun wirklich die Schuhe ausgezogen hat ist dieser Satz:

Die EJBler sind und bleiben die großen Macher. Sich in das Thema einzuarbeiten ist mühsam, weil man von vornherein sehr viele Sachen wissen und können muß

Hallo? EJBs sind nicht gerade dafür bekannt das sie eine große Fan Gemeinde haben. Praktisch sind Frameworks wie Spring und Hibernate erst richtig populär geworden eben weil sie deutlich einfacher zu handhaben sind. Das EJB 3 nun mit "POJO's" arbeitet liegt nicht zuletzt daran, das die Entwickler von Hibernate an der Spec zu EJB 3 mitgearbeitet haben.

Der Trend geht doch heute weg von "heavy-weight" frameworks, hin zu light-weight Frameworks die einfach zu erlernen sind (TCO!!) und sich auf den Projektbedarf zuschneiden lassen. Würden wir alle schön "streng nach BluePrint-Lösung" arbeiten, hätte sich an dem Monster EJB2 wohl nichts geändert. Wirkliche Innovationen finden außerhalb dieser heilen Blueprint Welt statt - von daher würde ich die "nicht-EJBler" nicht so leichtfertig abstempeln.

 

[miketech]

Hallo,

naja vielleicht ist EJB3 ja gar nicht mehr so schwer. Man muss ja auch immer unterscheiden, was einem die IDE vielleicht an Arbeit abnimmt.

Und EJB ist jetzt vielleicht nicht light-weight, aber vielleicht bietet es mir dafür Möglichkeiten, die ich mit light-weight Frameworks nicht erreichen kann?

Ich glaube jeder, der sich am Anfang mit J2EE und EJB beschäftigt fragt sich ernsthaft, wofür er das alles braucht, wenn das in anderen Frameworks doch soviel einfacher geht.

Gruß

Mike

 

[bronks]

Dabei übersiehst du, das J2EE auch nur ein Framework ist. Und wie bei jedem guten Framework, obliegt es dem Anwender (also in dem Fall dem Entwickler) welche Funktionen er daraus verwenden will - und welche nicht.

JEE ist eine ProgrammierSchnittstelle für ApplikationServer lt. Spec. Was ein Framework ist, kannst Du gerne bei Wikipedia nachlesen. Ein Framework hat keine Funktionen eine API dagegen schon.

Wer mit Servlets und JSPs gut leben kann, aber keine EJBs für die Objektpersistenz verwenden will nimmt eben etwas anderes, z.B. Hibernate.

Die WebAPI sehr praktisch, wenn man auf das große darunterliegende Arbeitspferd unproblematisch zugreifen will, welches auf Java basiert. Für irgendwelche dynamischen Internetseiten ist Java der reine Überfluss und für den Webentwickler unnötig umständlich. Dafür gibt es PHP, welches von IBM und Oracle seit fast einem Jahr neu entdeckt wird.

Die in den Core J2EE Patterns beschriebenen Design Patterns sind auch nicht darauf hin ausgelegt das sie nur mit J2EE Bordmitteln verwendet werden können. Im Gegenteil - diese Patterns sind zum Teil ganz allgemeingültig spezifiziert und z.T. älter als J2EE selbst.

Na also hiermit ist wohl belegt, daß man auf JEE Frameworks anwenden kann, aber JEE selbst keines ist.

... EJBs sind nicht gerade dafür bekannt das sie eine große Fan Gemeinde haben. Praktisch sind Frameworks wie Spring und Hibernate erst richtig populär geworden eben weil sie deutlich einfacher zu handhaben sind ...

Spring und Hibernate? Aha ... wohl aber nur in WebApps? Wenn es um WebApps geht, dann ist PHP um einiges Beliebter als Java, Spring und Hibernate zusammen.

... Das EJB 3 nun mit "POJO's" arbeitet liegt nicht zuletzt daran, das die Entwickler von Hibernate an der Spec zu EJB 3 mitgearbeitet haben ...

Naja, irgeneinen Grund wird es wohl dafür geben, warum Hibernate so verspätet und kurzfristig auf EJB3-ähnlichkeit umgebastelt wurde.

... Der Trend geht doch heute weg von "heavy-weight" frameworks, hin zu light-weight Frameworks die einfach zu erlernen sind (TCO!!) und sich auf den Projektbedarf zuschneiden lassen. Würden wir alle schön "streng nach BluePrint-Lösung" arbeiten, hätte sich an dem Monster EJB2 wohl nichts geändert. Wirkliche Innovationen finden außerhalb dieser heilen Blueprint Welt statt - von daher würde ich die "nicht-EJBler" nicht so leichtfertig abstempeln.

J2EE ist eine Spec, die von IBM, Oracle, BEA, SUN und ein paar anderen, als Hochleistungsenterpriseapplicationserver umgesetzt wurde. Ich beschäftige mich mit JEE weil ich damit EnterpriseApps realisieren will, wofür es gedacht ist, sonst wäre ich vor 4 Jahren bei PHP geblieben und hätte evtl GUIs weiterhin per HTTP verbunden. Das was ein alleinstehender Tomcat zu bieten hat macht man am besten mit PHP, weil man es insgesamt besser und unproblematischer einsetzen kann.

 

[LordSam]

JEE ist eine ProgrammierSchnittstelle für ApplikationServer lt. Spec. Was ein Framework ist, kannst Du gerne bei Wikipedia nachlesen. Ein Framework hat keine Funktionen eine API dagegen schon.

Vielleicht sollte man an der Stelle mal erwähnen, das der Begriff "Framework" in den letzten Jahren sehr strapaziert worden ist. In der Praxis ist es aber eben so, das niemand von JEE nur von der Spezifikation spricht. Verwendet wird JEE wie ein Framework. Deshalb werden einzelne JEE Komponenten auch immer wieder direkt mit einem Framework verglichen.

Aber was eine Sache nun ist, darüber haben sich die Leute schon immer gestritten und da werden wir uns auch nicht einige werden. Die Kernaussage von mir war, das man JEE nicht nur ganz oder garnicht verwenden kann. Und das ist auch gut so!

Die WebAPI sehr praktisch, wenn man auf das große darunterliegende Arbeitspferd unproblematisch zugreifen will, welches auf Java basiert. Für irgendwelche dynamischen Internetseiten ist Java der reine Überfluss und für den Webentwickler unnötig umständlich. Dafür gibt es PHP, welches von IBM und Oracle seit fast einem Jahr neu entdeckt wird.

so so, dann is also Java nur für Enterprise Applications gut und für alles andere im Web nimmt man dann also PHP, weil Java sowieso viel zu kompliziert ist?

Java ist nicht kompliziert - und die Bandbreite zwischen einer einfachen Homepage mit Gästebuch zu einer Enterprise Anwendung mit verteilten Transaktionen, 100.000+ concurrent usern und verschiedenen UIs (Web, Rich Client, Mobile Devices, ...) ist groß.

Es ist immer wichtig das richtige Werkzeug für die anstehende Aufgabe auszuwählen. JEE ist ein gutes Werkzeug, aber es eignet sich nicht für alle Anwendungsfälle. Deshalb haben alternative Bibliotheken, Frameworks oder wie immer du es nennen willst ihre Daseinsberechtigung.

Spring und Hibernate? Aha ... wohl aber nur in WebApps? Wenn es um WebApps geht, dann ist PHP um einiges Beliebter als Java, Spring und Hibernate zusammen.

Du solltest Dir mal die beiden Frameworks ansehen, dann wirst Du feststellen, das sowohl Spring als auch Hibernate in non-Web-Apps einsetzbar ist, was auch häufig der Fall ist. Insb. Hibernate ist ein reines "backend" tool, ganz egal was für's UI verwendet wird.

Naja, irgeneinen Grund wird es wohl dafür geben, warum Hibernate so verspätet und kurzfristig auf EJB3-ähnlichkeit umgebastelt wurde.

Ich glaube Du hast mich da missverstanden. EJB3 und Hibernate darf man nicht als Konkurenz zueinander sehen. Das sind unterschiedliche Werkzeuge für unterschiedliche Zwecke (wenngleich es da auch eine schnittmenge gibt). Hibernate hat zu dem Zeitpunkt große Erfolge gefeiert, wo über EJB2 heftigst diskutiert wurde, wo den Leuten klar geworden ist das es auch einfacher gehen muss. Es war doch eine tolle sache, das man von der art wie Hibernate ORM angegangen ist "lernen" konnte und diese Erfahrung mit hilfe der Hibernate-Entwickler in die Spec zu EJB3 übernommen hat. Ich finde das großartig, weil ich nun bei entsprechenden Projekten keine Bauchschmerzen mehr bekomme, wenn ich daran denke das wir dafür EJBs verwenden.

J2EE ist eine Spec, die von IBM, Oracle, BEA, SUN und ein paar anderen, als Hochleistungsenterpriseapplicationserver umgesetzt wurde. Ich beschäftige mich mit JEE weil ich damit EnterpriseApps realisieren will, wofür es gedacht ist, sonst wäre ich vor 4 Jahren bei PHP geblieben und hätte evtl GUIs weiterhin per HTTP verbunden. Das was ein alleinstehender Tomcat zu bieten hat macht man am besten mit PHP, weil man es insgesamt besser und unproblematischer einsetzen kann.

Wie schon erwähnt ist die Bandbreite an Anwendungen groß und auch wenn ich selbst PHP gern für kleinere Seiten benutze, so hat Java ohne JEE AppServer doch noch erheblich mehr zu bieten als PHP.

Aber um das nochmal klar zu stellen: JEE ist ein gutes Werkzeug (oder besser: Werkzeugkasten), aber es gibt viele Frameworks die ebenso ihre daseins-berechtigung haben. IMHO ist es eine Bereicherung für die Java-Welt, das ein Entwickler die Wahl zwischen verschiedenen Frameworks hat. Einsteiger sollten sich deshalb eher fragen "Was" sie überhaupt entwickeln wollen, um dann nach den passenden Werkzeugen zu suchen.

 

[mutex]

Zum viel bemühten Vergleich zwischen PHP und Java bzgl. WebApps:

Ich denke, daß so mancher Entwickler mit seinem C++ sehr glücklich ist. Weil aber heute so vieles auf's Web ausgelegt ist, kommt man oft um entsprechende Anforderungen nicht herum und mit den klassischen Sprachen nicht weit. Also landet man bei den üblichen Verdächtigen: Eben Perl und Co oder mitlerweile am ehesten PHP. Mit so einer Scriptsprache hat man schnell etwas gefummelt, aber es wird eben auch schnell gefummelt: Die Anwendung wächst und fliegt einem dann früher oder später komplett um die Ohren. Man muß schon sehr diszipliniert sein, um in PHP eine Applikation zu schreiben, die modular, wartbar und flexibel erweiterbar ist - aber Diszipliniertheit ist nicht unbedingt das Konzept von Scriptsprachen. Ist es auch flott und einfach, in eine Variable mal eben werweißwas reinstecken zu können, wünscht man sich, wenn diese Variable irgendwo her und über zwanzig verschiedene Funktionen von fünf anderen Kollegen kommt, die gute alte Typsicherheit zurück. Hier hoffe ich für mich persönlich mit Java ein wenig Licht am Horizont zu sehen, verspricht es doch, sich an "saubere" Programmierparadigmen anzulehnen und trotzdem mit diesen das Feld der WebApps zu bedienen. Dies ist jedenfalls meine Intention: Perl und PHP für den ersten "rapid Prototype" verwenden und diesen dann in Java umsetzen, um eine ordentliche Ausgangsbasis für die (Weiter)entwicklung zu schaffen.

Es geht an diesem Punkt vielleicht also gar nicht mal um die Frage EE oder nicht EE, sondern einfach nur darum, wie man in Java das realisiert, was man bisher mit Perl+TT+DBI oder PHP+Smarty+mysql gemacht hat. Und eben hier kann ich das "verwirrt sein" des ursprünglichen Posts voll und ganz nachvollziehen: Nun gut, ich nehme Servlets+JSP; oh hier gibt's Struts, daß einen dabei unterstützt, den Java-Code aus den JSP's rauszukriegen; hm, aber mit JSP2, Taglibs und JSTL kann man eben dies auch realisieren; okay, für ein einfaches Formular reicht wohl JSP, aber in dem Zusammenhang ist überall von JSF die rede - was bringt mir das überhaupt? Sollte ich mich mit JSF auseinandersetzen? Gut, guck ich's mir "mal kurz" an und wieder fliegen mit dutzende von Begriffen um die Ohren: Unterschiedliche Versionen der Spezifikation, Renderer, myFaces, Tobago undundund - und schließlich heißt's, ich sollte dabei besser doch auf Facelets anstatt auf JSP setzen. Vielleicht sollte ich JSF doch einfach vergessen? An dem Duke-Beispiel erkenne ich zumindest nicht, was es mir bringt!?! Okay, Unterstützung verschiedener Clients durch unterschiedliches Rendering oder sowas ... keine Ahnung. Aber wenn man sich darüber informiert, stolpert man wieder über andere Ansätze wie z.B. XSLT und Cocoon, anstatt Antworten zu finden. Neinneinnein, erstmal für den Einstieg kleine Brötchen backen: Ich mach jetzt Servlets+JSP als Ersatz für PHP+Smarty. Gut: Suche ich mal nach Beispielen ... was findet man? In Sachen JSP Documents bzw. JSPX eigentlich ziemlich wenig - allles nur in "alter" Scriptlet-Schreibweise ... schade, denn JSPX würde ich für 'ne saubere Sache halten und 'ne saubere Sache ist ja eben das, wo ich hin will. Okay: Wie benutze ich diese JSP's vernünftig als Template-System ... ich finde bei Sun Artikel von Anfang 2000, finde neue Begriffe wie Tapestry oder sonstwas und selbst in halbwegs aktuellen Büchern scheint nur die alte Schreibweise verwendet zu werden - wie ich das dann ordentlich in XML umsetze kann ich mir selbst ausdenken.

Gibt es irgendwo irgendeine kleine Beispielapplikation - und sei's das blöde Gästebuch - anhand derer man die aktuellen(!) Techniken mal nachvollziehen kann? Was ich bisher so gefunden habe war entweder so klein, daß man die Konzepte dahinter nicht erkennen kann (okay, statt input schreib ich jsf:irgendwas und dadraus wird dann ein html-input - na und?) oder so mit veralteten Ansätzen zusammengefummelt, daß ich's mit PHP allemal stukturierter hinbekäme (grummel)

Ich denke, es gibt unzählige Frameworks und dutzende von tollen Konzepten, aber man sieht vor lauter Bäumen den Wald nicht mehr: Und da wär's für den Einsteiger bei diesen Dingen vielleicht hilfreich, anstatt seitenweise Beschreibungen was man denn theoretisch alles damit machen könnte, einfach mal hier oder da etwas halbwegs praxisbezogenes zum anfassen zu haben.

 

[bronks]

Eigentlich und überwiegend sind wir schon gleicher Meinung. Ich sehe viel zu oft total überforderte Computer und überlastete Netzwerke, die mit Problemen kämpfen, die man mit einem angemessenen EnterpriseServer und einer dafür ausgelegten App nicht hätte.

... so so, dann is also Java nur für Enterprise Applications gut und für alles andere im Web nimmt man dann also PHP, weil Java sowieso viel zu kompliziert ist? ...

Damit meine ich mehr, daß die Webhoster damit nicht zurecht kommen. Hab schon viel Geld nichtfunktionierenden JavaWebspace ausgegeben. PHP ist dagegen ein unproblematischer Genuss.

... Es ist immer wichtig das richtige Werkzeug für die anstehende Aufgabe auszuwählen. JEE ist ein gutes Werkzeug, aber es eignet sich nicht für alle Anwendungsfälle. Deshalb haben alternative Bibliotheken, Frameworks oder wie immer du es nennen willst ihre Daseinsberechtigung ...

Ich nimm momentan immer J2EE und lutsche den gesamten Patternkatalog durch weil ich das ganze mittlerweile aufsagen kann, wie ein Gedicht. Mir kann niemand sagen (hat allerdings schon mal jemand probiert), daß EJB für ein einfaches Adressbuch ungeeinget ist. Ich komme damit sicher genauso schnell vorwärts, wie jemand anderer mit etwas anderem; nur weiß ich was mit meiner App passiert, wenn diese extrem belastet wird.

Du solltest Dir mal die beiden Frameworks ansehen, dann wirst Du feststellen, das sowohl Spring als auch Hibernate in non-Web-Apps einsetzbar ist, was auch häufig der Fall ist. Insb. Hibernate ist ein reines "backend" tool, ganz egal was für's UI verwendet wird.

Klar, aber das ist ein völlig anderes Thema bei dem wir uns einig sind.

Ich glaube Du hast mich da missverstanden. EJB3 und Hibernate darf man nicht als Konkurenz zueinander sehen. Das sind unterschiedliche Werkzeuge für unterschiedliche Zwecke (wenngleich es da auch eine schnittmenge gibt).

So ist es, aber wenn ich schon einen Server, wie z.B. bei einer WebApp starten muß, dann nehm ich einen EnterpriseServer und nicht Tomcat mit Hibernate und Spring.

 

[bronks]

... JSF ...

Da hat man genau das gleiche Thema am Hals wie z.B.: EJB vs. irgendetwas anderes.

Gibt es irgendwo irgendeine kleine Beispielapplikation - und sei's das blöde Gästebuch - anhand derer man die aktuellen(!) Techniken mal nachvollziehen kann? ...

Es bietet sich der PetShop an ... Da wird EJB3 mit JSF in der schönsten Form durchgekaut. Ich habe diesen auf dem SJSAS9 mit PgSql laufen.

 

[miketech]

Hallo,

@mutex: Wieder einmal sprichst Du mir aus der Seele Es geht nicht darum, dass man einfach nur von PHP wegmöchte, sondern es geht darum, dass man wartbareren und modulareren Code bekommt.

Nun gibt es aber ja z.B. auch Ruby On Rails, die schon zu deutlich besserem Code verleiten. Und man kommt sehr schnell bei dem ganzen Java-Kram zu dem Punkt, wo man sich denkt: Bringt mir das überhaupt noch irgendwas? Mir kann keiner sagen, was ich nun davon für Vorteile habe, ich habe bis heute nicht verstanden, wann ich was nehmen soll und irgendwann möchte man am liebsten alles hinschmeißen und doch die Write-And-Click-On-Play Version Ruby On Rails, oder ASP.NET nehmen.

Aber dennoch ist es bei mir manchmal diese Komplexität, die mich reizt und die einen dann doch nicht loslässt. Irgendwas muss einem ja mehr geboten werden, man muss es nur noch finden

Ich habe mir nun ein JSF Buch ausgeliehen und hier wird am Anfang schon kurz gezeigt, wo der Vorteil von JSF gegenüber z.B. derselben Seite in Form von JSP mit JSTL liegt. Im Grunde ist es kürzerer Code. Desweiteren bietet mir JSF auf Events zu reagieren, ohne das ganze per Hand zu parsen. Sobald ich mit dem Buch weiter bin kann ich dazu vielleicht mehr sagen

Aber selbst der Autor schreibt: JSF ist geeignet für komplexe Weboberflächen, die eine Menge Interaktion mit dem Benutzer fordert. Für kleine dynamische Webseiten, die nur darauf ausgelegt sind einige wenige Inhalte aus einer Datenbank anzuzeigen ist man mit JSP meist schneller am Ziel.

Ich denke mir bei sowas nur immer: ASP.NET Anwendungen sind z.B. sehr schnell zusammengeklickt und laufen. Aber der Code von ASP.NET Anwendungen, also von den Webseiten ist ähnlich derer mit JSF. Nur hat Visual Studio eben einen netten Editor, mit dem ich das ganze zurechtbasteln kann. Sobald ich das per Hand machen müsste wäre ich nicht schneller, als mit JSF. Man sollte also die IDE nicht vernachlässigen. Und wenn meine Lieblings-IDE nun auf JSF setzt, dann werde ich auch JSF benutzen und schon ist die Frage nach dem "Was benutze ich nun" schnell gelöst.


Ansonsten muss man das ganze wohl recht pragmatisch angehen. D.h. ich nehme mir eine Anwendung vor und wähle dafür JSF. Ich habe mich für JSF entschieden, weil es für mich den Eindruck macht, dass es State of the Art ist und es mir im Vergleich zu Tapestry besser gefällt, vom Code her. Wie nun Facelets usw. damit zusammenhängen weiß ich noch nicht.

Aber wenn ich nun JSF verwende, verwende ich auch schnell Servlets, JSP und JSTL. Und dann begreift man schon, was das alles macht.

Kompliziert wird es imho erst, wenn sowas wie Spring, JBoss Seam, EJB usw. ins Spiel kommt. Weil hier gibt es Überlappungen. Hier übernehmen viele die selbe Aufgabe. Und ein Vergleich ist nicht in 5 Minuten getan, da es, wie mutex schon sagte einfach keine Informationen gibt, was wo besser ist. Das muss ich selbst erarbeiten und das braucht Zeit, die man nicht immer investieren will. Man möchte ja nicht alles 10 mal programmieren, jeweils mit einem anderen Framework. Sondern entscheiden: Ja, das nehme ich, weil...

Also ich bin für jeden Link dankbar, der mir eine Übersicht gibt, was wo wie wann für was besser geeignet ist Solange werde ich einfach weiter Bücher lesen, in der Hoffnung, dass hier entsprechende Informationen enthalten sind, oder ich mir nach ein paar Büchern selbst ein Bild machen kann, wann sich was besser eignet.

Gruß

Mike

 

[mutex]

Da hat man genau das gleiche Thema am Hals wie z.B.: EJB vs. irgendetwas anderes.

Genau dieses Thema "Enterprise oder nicht Enterprise" hatte wir hier ja schon ein paar mal. Damit ihr mich korrigieren könnt, falls ich auf dem falschen Dampfer bin, mal meine naive sicht der Dinge: Für die "einfache" Webseite als PHP-Ersatz mache ich Servlets, Beans und JSP auf einem reinen Servlet-Container. Wenn die Anwendung nicht allzu umfangreich ist, dann kann ich das ganze ab Servlets 2.4 und JSP 2.0 (mit JSTL und eigenen Custom-Taglibs) auch ganz ohne Struts und Co sauber MVC/Model2-Like aufbauen. Habe ich in der DB eh nur drei Tabellen, dann kann ich die auch direkt per JDBC handeln und brauche die nicht per Hibernate oder sonstwas zu abstrahieren. Erst wenn die Zusammenhänge dann komplexer werden, sollte ich entweder ein verdammt gutes Konzept haben, oder aber mir ein Framework suchen, daß mir ein solches vorgefertigt liefert: Sehe ich in meinem Code mehr SQL als Java, dann ist's vielleicht doch Zeit für ein ORM - und dann aber lohnt der Aufwand der Einarbeitung auch. Wenn ich aber schließlich Daten auf mehreren Servern hin und herschieben, Nachrichten unter unterschiedlichen Komponenten austauschen und das ganze auch noch irgendwie transaktionssicher sein soll und synchronisiert werden muß ... na, dann werde ich mit EJBs glücklich - und auch wenn letztere oft als komplex oder kompliziert beschrieben werden: Im Vergleich zu dem Aufwand, sich entsprechende Eigenschaften selbst zu stricken, erscheinen mir EJBs (zumindest die 3er) geradezu traumhaft einfach und komfortabel. Aber auch die ein oder andere Enterprise App dürfte einen Frontend haben und damit sind wir wieder ganz am Anfang: Servlets, JSP und Co., mit denen sich somit auch die "ernsthaften" Entwickler auseinandersetzen müssen (weil auch diese Pipi-Sachen sind eben doch auch ausdrücklich und nicht ohne Grund Bestandteil der EE-Spec). Was mich als Einsteiger aber frustet ist, wenn ich alleine in Sachen JSP an den simpelsten Fragen scheitere und bei Recherchen nur so mit Begriffen erschlagen werde, ansatt einfach mal einen brauchbaren Ansatz in Form von ein paar Zeilen Beispielcode zu finden.

 

[miketech]

Hi,

jetzt habe ich ein kleines Verständnisproblem:

Manchmal habe ich den Eindruck, dass MVC nicht richtig verstanden wird. Die Programmlogik gehört NICHT ins Servlet. Ein Servlet ist eine Kommunikationsschnittstelle zwischen Anwendung und Server. Ein Controller dient lediglich zur Anwendungskontrolle, sprich: setzen von Zuständen im Model und Auswahl der View. Die Anwendungslogik wird übrigens dem Model zugeordnet.

Und die Logik implementiere ich als JavaBean? Ist das dann nichts anderes als eine Java-Klasse mit zum Teil statischen Methoden, mit denen ich irgendwelche Logik ausführe? Bzw. vielleicht ein Singleton?

D.h. eine große Klasse, die die komplette Logik enthält? Oder wie darf ich mir das vorstellen?

Gruß

Mike

 

[SnooP]

die Logik kann man doch auf dem Server in Form von POJOs implementieren... also ganz einfache ganz normale Javaklassen die das Modell repräsentieren... diese kann man testweise auch über eine ganz normale main-klasse aus starten etc... - würde immer so vorgehen und erst am ende gui-implementierungen (jsp) überlegen und schnittstellen nach außen bereitstellen... nichts anderes brauchst du dann für servlets oder home-interfaces bei ejbs oder sonstigem... denn auch bei ejbs ist man nicht dazu verdonnert grundsätzlich sämtliche logik in beans zu packen.

Und verwechselt bitte nicht Javabeans mit EJBs - ich weiß dann manchmal hier nicht, ob tatsächlich javabeans gemeint werden oder halt die komplexeren ejbs

 

[HLX]

Und die Logik implementiere ich als JavaBean? Ist das dann nichts anderes als eine Java-Klasse mit zum Teil statischen Methoden, mit denen ich irgendwelche Logik ausführe? Bzw. vielleicht ein Singleton?

D.h. eine große Klasse, die die komplette Logik enthält? Oder wie darf ich mir das vorstellen?

Eine große Klasse schonmal garnicht. :wink:
Vergiss bitte nicht, dass Java eine objektorientierte Sprache ist. Das bleibt sie auch in der Web-Entwicklung. Bau keine Riesenklassen sondern identifiziere sinnvolle Objekte und implementiere diese.

Also: Die Logik gehört nicht ins Servlet, sondern im einfachsten Fall in normale Java-Klassen. Stell dir einfach vor, du möchtest deine Web-Anwendung alternativ als Standalone mit Swing-Frontend anbieten. Dann liegt die Logik im Servlet denkbar ungünstig. Alles was nicht speziell mit der Web-Anwendung zu tun hat, z.B. eine Kalkulation sind daher im Backend in Java-Klassen unterzubringen. Dann kannst zu sie später für andere Zwecke wiederverwenden. Schließlich wollen wir ja modular bleiben.

Für das Servlet bleiben somit Steuerungs- und andere webspezifische Aufgaben übrig. Hier wird z.B. der Berechnungsvorgang im Backend angestoßen, es werden die Werte für die JSP-Ausgabeseite gesetzt und die Navigation geregelt, z.B. gehe im Fehlerfall auf Seite X und bei Erfolg auf seite Y.

Eine JavaBean ist eine Klasse, die in erster Linie Zustände eines Objektes hält. Diese Zustände werden durch Attribute bzw. Variablen repräsentiert, die mit einem Getter zugegriffen und einem entsprechenden Setter verändert werden können. Dabei heißen Getter und Setter immer getXy und setXy wobei XY der Variablenname ist (im Getter und Setter immer Großbuchstabe am Anfang des Variablennamen). Wird die Form eingehalten können JSPs und auch Hibernäte prima mit den Beans umgehen.

Es ist dir freigestellt auch Logik in der Bean unterzubringen, je nachdem ob es im Sinne der Objektorientierung o.k. ist.

Ein Wort zu Singletons: Mit Singletons immer sparsam umgehen. Sofern die Gefahr besteht, das ein Anwender einem anderen Anwender alles zerschießt sollte man sich davon verabschieden. Das gilt sowohl im Frontend als auch im Backend. Für den Webbereich solltest du sessionbasiert arbeiten. Dabei hilft dir ein SessionContext.

Ansonsten kann ich nur nochmal raten sich erst mit der Basismaterie auseinander zu setzen, sprich: Web Allgemein, dann Application Server/Tomcat, dann Servlets und dann JSP. Wenn man die Servlet-Technologie einmal richtig verstanden hat, dann merkt man, dass bei Struts, JSF etc. auch nur mit Wasser gekocht wird. Vieles erschließt sich einem deutlich schneller und der Nebel lichtet sich.

Also nochmal:
- Die komplette Web-Entwicklung in Java, egal was auch immer es ist, baut auf der Servlet-Technologie auf. Logisch, weil unser Tomcat oder AppServer verarbeitet HTTP mit Servlets.
- JSPs werden vom Tomcat/AppServer kompiliert - in was? In Servlets.
- Struts, JSF usw. - alles Servlet-Technologie.
Daraus folgt: Servlet-Technologie = unerlässliches Basiswissen für Java-Web-Entwickler

 

[miketech]

Hi,

ok dann brauch ich noch mehr Bücher

Mir ist prinzipiell schon klar, wie ich in JSPs auf Beans zugreife. Das ist auch ne ganz feine Sache.

Mein Problem ist nur folgendes:

Angenommen ein Login, mit Username + Passwort.

Wenn der User nun auf "Login" klickt wird eine Methode in meinem Servlet aufgerufen. Hier kann ich nun überprüfen welcher Knopf geklickt wurde und die Inhalte der Eingabefelder abfragen.

Nur wo packe ich nun die Kontrolle hin, ob Username und PW stimmen? Rein intuitiv hätte ich nun überprüft, ob der Login Button aufgerufen wurde und dann eine Methode "checkLogin" aufrufen. Nur wo sitzt diese Methode? Das gehört ja in die Anwendungslogik. Ich könnte eine Klasse "User" erstellen mit einer Methode "checkLogin". Dann würde ich im Servlet eine neue Instanz der Klasse "User" erstellen und die Methode aufrufen.

Ist das die korrekte Vorgehensweise?

Gruß

Mike

 

[HLX]

Das ist eine mögliche Vorgehensweise. Alternativ kannst du 'checkLogin' an der LogIn-Bean implementieren. Finde ich pers. schöner.

Im Servlet holst du dir die Bean und rufst die Check-Methode auf. Die Methode könnte eine Liste von Fehlermeldungen zurückgeben. Ist die Liste leer (Erfolgsfall) navigiert das Servlet auf die nächste Seite. Sind fehler enthalten, packt sie das Servlet an den Request und navigiert zurück zur Eingabeseite.

Im Erfolgsfall wird im Servlet ein neuer Benutzer erzeugt und an die Session gehangen.

 

[SnooP]

Wo soll der User denn einloggen - rein logisch... irgendwo muss es ja was geben - nen Ding - was alles repräsentiert also auch die Menge der User zugehörig sind... dieses Ding sollte ne Methode login(user, passwd) haben und die kann dann meinetwegen nochmal checkLogin aufrufen - die Methode kann private in der selben Klasse hocken...

ooder aber man schreibt eine Factory-Klasse die User-Objekte erstellen kann, die mit der Methode createUser überprüft, ob die Eingabedaten richtig sind, wenn ja, dann wird ein User-Objekt erzeugt mit dem du weiterarbeiten kannst... z.B. halt eine login-Methode deines Systems aufrufen jetzt mit übergebenem User-Objekt - also grundsätzlich gibts da sicherlich mehrere Möglichkeiten wie man vorgehen kann

 

[miketech]

Hi,

ah das ist ja schon irgendwie super

Also erzeuge ich dann aber in meinem Servlet eine neue Instanz der Bean, oder? So habe ich es zumindest in einigen Beispielen gesehen, die ich mir angeschaut habe.

Noch eine Kleinigkeit:

Ich kann ja im JSP eine Bean verwenden, z.B. eine User Bean. Kann ich die verwenden, um gleich die Inhalte der Eingabefelder zu speichern? Wenn ja: Wie greife ich denn im Servlet auf diese Bean zu und kann z.B. Attribute ändern, die dann im JSP wieder zur Verfügung stehen?

Oder geht das dann eher in Richtung JSF?

Gruß

Mike

 

[HLX]

Also erzeuge ich dann aber in meinem Servlet eine neue Instanz der Bean, oder? So habe ich es zumindest in einigen Beispielen gesehen, die ich mir angeschaut habe.

Nein, du HOLST dir die Bean. Du erzeugt sie nur dann im Servlet, wenn du JSP-Seiten ausschließlich über Servlets aufrufst, also den direkten Aufruf einer JSP-Seite unterbindest. Solltest du allerdings beim Start der Anwendung sorfort auf eine JSP-Seite gehen wird die Bean mittels des Tags <jsp:useBean> erzeugt. Du kannst Sie dann unter Ihrem Namen mittels der Methode 'getAttribute' im Servlet zugreifen.

Ich kann ja im JSP eine Bean verwenden, z.B. eine User Bean. Kann ich die verwenden, um gleich die Inhalte der Eingabefelder zu speichern? Wenn ja: Wie greife ich denn im Servlet auf diese Bean zu

S.o. - nimm für das LogIn-Formular eine LogIn-Bean. Fülle diese in der JSP-Seite, leite die Anfrage an ein Servlet hole dir die Bean mittels getAttribute in Servlet, dann checke/validiere die Login-Informationen und lade anschließend die Benutzerdaten.

und kann z.B. Attribute ändern, die dann im JSP wieder zur Verfügung stehen?

Ja, wenn die Bean mindestens scope=session hat.

Oder geht das dann eher in Richtung JSF?

JSF und Struts sind Frameworks die das, was du hier tust einfach etwas komfortabler machen. Bei Struts hast du z.B. in der Action (Servlet) statt 'doPost(request,response)' eine execute-Methode die zusätzlich die Bean schon als Parameter dabei hat.

 

[miketech]

Ah super, danke schön!

Gruß

Mike

 

[miketech]

Hi,

noch eine Frage:

Den Inhalt eines Input-Feldes kann ich nicht direkt mit Attributen einer Bean verbinden, oder? Ich muss schon im Servlet mit getParameter("Feld1") usw. jedes InputFeld abfragen.

In allen Beispielen, die ich bisher gesehen habe werden Beans nur in JSP verwendet, um z.B. direkt aus einem JSP eine Funktion einer Bean auszuführen. Da das aber ja in die Logik reingehört, habe ich das nun im Servlet, bzw. wird vom Servlet aufgerufen.

Ist die Bean dann nur dafür, dass ich vom Servlet aus wieder Daten an ein JSP übertragen kann?

Gruß

Mike

 

[HLX]

Die Bean (Model) ist dafür da, die Werte für deine JSP-Seiten zu halten. Die JSP-Seiten (View) enthalten nur die Darstellung, keine Inhalte. Über das Tag <jsp:getProperty> kannst du jedes GUI-Element mit einem Bean-Wert verknüpfen. So wird immer der aktuelle Wert eines Bean-Attributes im GUI-Element angezeigt, auch wenn du es im Servlet z.B. im Rahmen der Validierung verändert hast.

Den Inhalt eines Input-Feldes kann ich nicht direkt mit Attributen einer Bean verbinden, oder? Ich muss schon im Servlet mit getParameter("Feld1") usw. jedes InputFeld abfragen.

Genau. Das ist leider etwas unschön. Wäre es schön wenn einem diese Arbeit ein Framework abnehmen könnte... :wink:

Und da kommen wieder Struts und JSF in spiel. Hier werden die Bean-Attribute "richtig" an die Eingabefelder gekoppelt - bei Aufruf der o.g. execute-Methode in der Action von Struts sind die Werte der Input-Felder bereits in die (Form-)Bean eingepflegt.

 

[miketech]

Aha! So langsam macht das alles Sinn Ich hab ja auch im Form-Tag ein Attribut "action", welches mir das Ziel-Servlet angibt. Das muss ich ja nun immer anpassen, wenn sich eine URL ändert, oder der Pfad in dem die Datei sitzt. Das ist auch etwas, was mit JSF komfortabler wird, richtig?

Gruß

Mike

 

[HLX]

Aha! So langsam macht das alles Sinn Ich hab ja auch im Form-Tag ein Attribut "action", welches mir das Ziel-Servlet angibt. Das muss ich ja nun immer anpassen, wenn sich eine URL ändert, oder der Pfad in dem die Datei sitzt. Das ist auch etwas, was mit JSF komfortabler wird, richtig?

Gruß

Mike

das JSF-Framework geht einen Schritt weiter. Hier hast du mit Servlets garnichts mehr zu tun. Das FacesServlet von JSF übernimmt alle nötigen Servlet-Operationen. Mit dem Attribut "action" rufst du direkt eine Methode an deiner Bean auf. Beans werden in der faces-config.xml registriert, so weiß das FacesServlet was aufgerufen werden muss. In der Bean sollte dann deinerseits die Validierung der Eingaben, und das Anstoßen der Backend-Operationen erfolgen.

(EDIT: Validierung in der Bean ist natürlich Quatsch - das ist bei Struts so, bei JSF wird ereignisgesteuert mit Validatoren gearbeitet).

Die Methoden, die du in der Bean von JSP aus aufrufst sollten einen String zurückgeben. Anhand dessen wird entschieden wohin navigiert wird. Dazu sind für jeden String in der faces-config.xml Navigationsregeln zu hinterlegen.

 

[miketech]

Ah, ich verstehe. Genial, danke.

Dann probier ich nun noch bisserl mit JSP und Servlets rum und dann teste ich mal JSF.

Gruß

Mike

 

[mutex]

Hm, jetzt wird's ja doch langsam mal etwas konkreter *freu* .... da will ich doch gleich auch mal meine Fragen los werden:

Bei dem Beispiel 'Login' würde ich vermuten, daß das weder in eine JSP noch in ein "standard" Servlet reinkommt, sondern dies ein klassischer Kandidat für einen (Security-)Filter wäre (womit wir wieder bei dem Thema ständig neuer Begriffe wären ;-)).

Der geschütze Bereich wird im allgemeinen eine Vielzahl von Seiten enthalten und da möchte man nicht in jede "jsp:useBean" und "c:if eingeloggt" usw. reinschreibseln - wäre viel cut'n'paste, aber vorallem kritisch, wenn man's mal vergißt ... meiner unqualifizierten Meinung nach hätte das also nix in der JSP zu suchen, oder?!?

Auch bei einem "normalen" Servlet müßte immer genau dieses Servlet angesprochen werden: Das würde zu Verrenkungen führen, damit der User daran gehinder wird, Seiten des geschützen Bereichs direkt per URL anzusprechen ... denke, daß sollte man sich auch eher schenken - oder was spräche dafür?!?

Mein Ansatz wäre in diesem konkreten Beispiel daher ein Filter (javax.servlet.Filter) in einen Chain auf meinen geschützend Bereich z.B. "/restricted/*" zu mappen: Finde ich in der Session eine Authentifizierung, dann wird nix, also einfach nur ein chain.doFilter() gemacht; andernfalls: Finde ich Request-Parameter mit den Login-Daten, dann versuche ich den User zu authetifizieren; finde ich keine Login-Daten oder kann der User nicht authetifiziert werden, dann schicke ich Ihn auf die Login-Seite (Request-Dispatching oder Ausgabe eines HTTP-Redirects) und breche die weitere Ausführung ab in dem einfach kein doFilter auf dem Chain aufgerufen wird.

Zu der Sache mit der User-Bean: Die könnte - wenn mein obiger Ansatz so okay ist - einfach vom Filter in den Request-Scope gesetzt werden und dann in allen JSP's im geschützen Bereich genutzt werden (als "Hallo ${user.name}" und sowas).

Meine Frage wäre hier: Darf/soll eine solche Bean nur Getter und Setter enthalten? Im Servlet sähe das ziemlich blöde aus (setLogin(), setPasswd, setDoAuthenticate, getIsAuthenticated). Hübscher wäre ja doch ein authenticate(login,passwd) auf der Bean: Darf man sowas, oder ist das schlechter Stil?!?

Und auch wenn's im Servlet klappt auf Methoden zuzugreifen die nicht mit get oder set beginnen (für's Servlet ist eine Bean ja einfach nur eine Klasse): Im JSP wird's dann schon heikler (getProperty will natürlich nicht und mit der EL bin ich auch noch nicht drangekommen) ... das find ich teilweise 'n bißchen hässlich, weil sich in meiner JSP dann z.B. ein "Hallo <c:if test=${user.isMale}>Herr ...." fein macht, wenn ich das Objekt aber auch in Servlets verwende, dann sieht "user.getIsMale();" ziemlich blöde aus.

Im Momet mach ich's so, daß ich zu so einem getIsMale(), getHasChildren() oder sonstwas immer noch ein "isMale() { return this.getIsMale(); }" schreibe. Was wäre denn hier "sauber" oder "standard"?

 

[HLX]

Eine Bean darf durchaus auch andere Methoden enthalten. Man sollte dabei allerdings die Objektorientierung im Auge behalten.

Bei JSF ist dies sogar ausdrücklich vorgesehen, da der Controller (MVC) bereits vorimplementiert ist und man daher als Benutzer gezwungen ist direkt aus JSP mit der Bean zu kommunizieren, sprich die Authentifizierungsmethode aufzurufen.

 

[miketech]

Ganz kurz dazu:

Sind für das, was Mutex vor hat sowas wie z.B. Session Beans (EJB) geeignet? Der User meldet sich an und ich erzeuge eine Session Bean mit seinen Daten.

Aber dann muss ich dennoch überall überprüfen, ob so eine Bean existiert, damit der User keinen Zugang auf die unerlaubten Bereiche hat. Wie gehe ich damit um?

Gruß

Mike