Welches Framework könnt ihr empfehlen?

[Ande]

Hallo Leute,

ich soll für ein Projekt (so eine Art Fragebögen mit versch. Benutzern, I18N, evtl. Ajax)
ein Framework wählen. Habe mir ein paar Frameworks angeschaut, bin mir aber nicht schlüssig welches ich verwenden soll.

Was ich benötige:
- Model View Controller Ansatz (Model 2 Architektur)
- I18N
- evtl Ajax-Anbindung
- Benutzerverwaltung, Benutzervalidierung
- EJB, Persistence ist nich wichtig.

Das ganze soll dann in einem Tomcat laufen.

Ich habe ein paar Frameworks in die nähere Auswahl genommen und ein bisschen angeschaut: Spring, Struts, Grails(Groovy) und JSF.

Aber so genau weiss ich noch nicht welches für meine Zwecke am besten geeignet wäre.

Welches könntet ihr hinsichtlich meiner Anforderungen empfehlen?
Wo zB bekomme ich eine Benutzerverwaltung und Security so gut wie geschenkt?
Wie kann ich AJAX mit einbinden (bei JSF gibts zB ajax4jsf, das habe ich schon gesehen)
Welches ist eher untauglich?
Welches ist für welche Anforderung gut?
In welches kann man als Java/JSP/Servlet Programmierer schnell einarbeiten?
Welches andere Framework könnt ihr noch empfehlen? Hab viel über Tiles gehört hier im Forum?


Ich würde mich sehr auf Antworten freuen.

Gruß
Andrea

 

[Jockel]

Wird dir wahrscheinlich auch nicht weiterhelfen, beschäftigt sich aber mit der Thematik: http://evolutionarygoo.com/blog/?p=94

 

[ronny]

Hallo,

ich kann auch noch folgendes Framework empfehlen:

www.jwic.de

Ich habe das Framework u. a. für meine Diplomarbeit verwendet
und bin super damit zurecht gekommen. Kannst dir ja mal anschauen.

 

[KSG9|sebastian]

www.zkoss.org

Ajax - Imho ganz in Ordnung. Hat aber so seine Tücken. Die Doku ist etwas spärlich, das Foruma ber recht gut.

 

[Ande]

Also ich habe nochmal ein bisschen weiter gesucht.
Meine Anforderungen erfüllen ja soweit fast alle gängigen Frameworks.
Ajax-Anbindung, I18N, MVC, alles kein Problem.

Das Projekt wird auch nicht soo groß werden, im Prinzip könnte man es auch mit ganz normalem Servlets/JSB/Beans machen, aber deswegen such ich ja ein Framework, dass mir ein bisschen die Arbeit abnimmt.

Es soll so aussehen: eine Art Fragebogen mit verschiedenen Fragen (Multiple joice, one joice, ja/nein, zahlen, schätzungen).
Diese sollen auch wenn möglich leicht anpassbar sein (also zB die Fragen anhand eines Bildes (Imagemap) oder ähnliches beantworten).
Was ich noch brauche ist eine Benutzerverwaltung, Authentifizierung, Adminoberfläche.
Und da wäre es gut wenn man vom Framework eine Hilfe bekommt, zB dass die Verwaltung der Benutzer in Gruppen oder so relativ einfach macht.

JSF gefällt mir prinzipiell sehr gut, könnte mir vorstellen dass die Komponenten gut damit gemacht werden können. Ist nur die Frage: inwiefern hilft mir JSF mit den Sachen drumherum. Login der Benutzer, Sicherheit usw..

Oder kann ich da JSF vergessen?

Das Dependency Injection von Spring hört sich auch gut an, aber im Prinzip is das doch bei fast jedem so dass ich in XML Files die Objekte hinzufügen kann, oder liege ich hier total falsch? Was ist der Vorteil von Spring gegenüber anderen Frameworks?

Was ist mit dem neuen Struts? Taugt das was, kann das mir ein bisschen die Arbeit abnehmen?

Fragen über Fragen. Bin im Moment ein bisschen frustriert, habe mir viel zu den verschiedenen Frameworks durchgelesen, und irgendwie könnte ich mir jedes für mein Projekt vorstellen.

Turbine hab ich mir gerade auch mal angeschaut, da scheint das mit der Benutzerverwaltung gut zu laufen. Würde sich Turbine lohnen? Auch in Hinsicht auf Einarbeitszeit? Mit JSP/Servlets/Beans komme ich prinzipiell gut klar.

Würde mich auf Antworten freuen

Gruß
Andreas

 

[Fats]

Also ich habe nochmal ein bisschen weiter gesucht.[...]
Fragen über Fragen. Bin im Moment ein bisschen frustriert, habe mir viel zu den verschiedenen Frameworks durchgelesen, und irgendwie könnte ich mir jedes für mein Projekt vorstellen.[...]

Das Gefühl kenne ich! Man hat eine ungeheure Auswahl vor der Nase, in 5 Minuten versteht man von jedem nur den ersten Ansatz und denkt sich "wow!". Nach einer Woche Arbeit damit bekommt man langsam ein Gefühl für das neue Baby und nach einem Monat merkst Du, daß Du plötzlich vor einer Wand stehst. Nach ein paar nervenden weiteren Tagen hast Du die Wand erklommen und stellst, wenn Du unten bist, fest, daß es auch eine Tür gegeben hätte Wieder nach einiger Zeit gibt es beim Querlesen plötzlich die Erkenntnis, daß es mittlerweile ein anderes neues Produkt gibt, das all das, was Du in den vergangenen Monaten mühsam zusammen gflickt hast, nun mit zwei Mausklicks macht, wo es keine Mauern gibt und überhaupt viel toller ist ... eine neverending Lovestory!

Zu JSF: JSF wurde unter Einbeziehung der Erfahrungen von Struts gebaut. Der Vater von Struts (Name?) war/ist mit im Boot bei der Konzeption von JSF. Insofern sollte JSF die Vorteile, Ideen von Struts in sich vereinen - theoretisch! Ich kenne aber Struts nicht und hab bei JSF grade mal an der Oberfläche gekratzt!

Das nur mal so zwischendurch
Viele Grüße
Fats

 

[schalentier]

Also auch auf die Gefahr hin, dass ich vollkommen falsch liege, aber ich kann dir nur empfehlen (bei dem beschriebenen Projekt) mal auf andere, Nicht-Java Frameworks zu schauen. Das geht natuerlich nur, wenn Java keine zwingende Anforderung ist. Aber ich denke, mit z.b. Ruby on Rails oder einem aehnlichen Projekt (gibts Tausende in fast allen Sprachen), kannst du dein Projekt weitaus schneller realisieren. Konkret fuer RoR gibts uebrigens mehr oder weniger gute Ready-To-Use Benutzerverwaltungen (Stichwort: Role Based Authentication)...

Nur so am Rande als Denkanstoss.

 

[Fats]

[...] aber ich kann dir nur empfehlen (bei dem beschriebenen Projekt) mal auf andere, Nicht-Java Frameworks zu schauen. [...]

@Schalentier: Was hast Du für Erfahrungen: Denkst Du, daß Java nur für die wirklich großen Projekte geeignet ist? Und alles, was unter einem Levvel-XY liegt, sollte man besser mit anderen Sprachen/Tools umsetzen?

Viele Grüße
Fats

 

[schalentier]

Also, auch auf die Gefahr hin, dass ich mir jetzt hier ne Menge Feinde machen koennte...

Ich bin ueberzeugt, dass J2EE (bzw neuerdings JEE) in viel zu vielen Projekten eingesetzt wird, wo man besser darauf verzichtet haette. J2EE macht meiner Meinung nach wirklich nur in grossen Grossprojekten Sinn, besonders wenn man mit EJBs anfaengt. Auch wenn inzwischen viel getan wurde, und das Handling selbiger stark vereinfacht wurde (verglichen mit EJB2.X), das Haupteinsatzgebiet sind verteilte Umgebungen (mehrere physikalische Server, auf dem das Geschaeftsmodell verwaltet/berechnet/etc wird). Fuer alles andere sind es eher Kanonen auf Spatzen und so.

Nicht falsch verstehen, das gilt wirklich nur fuer J2EE, nicht fuer Java im Allgemeinen. Z.B. koennte man eine Anwendung deiner Art mit der ganz normalen Servletfunktionalitaet umsetzten, jedoch stoesst man dabei sehr schnell an Punkte, wo man sich masslos aergert, weil Framework XYZ das doch alles viel besser/flexibler macht. Und genau da springen die Skriptsprachen dieser Welt ein, denn sie sind wesentlich flexibler und mitunter auch einfacher als Java. Vielleicht is die Anwendung am Ende nicht sooo performant, wie sie haette sein koennen, aber man hat auch nur einen Bruchteil der Zeit in das Verstehen der Frameworks gesteckt. Ruby on Rails ist ein ziemlich gutes Beispiel, die Grundideen setzen sich nun zunehmend auch im Java Umfeld durch (zb Grails).

Nicht zu unterschaetzen ist natuerlich der Umstand, dass man sich mit kleineren "Spielprojekten" gut in eine Technologie wie eben J2EE einarbeiten kann. Soll das ganze am Ende jedoch im produktiven Einsatz fahren, wuerd ich das nochmal ueberdenken, denn einen JBoss/Tomcat zu konfigurieren, so dass er wirklich rund laeuft, ist alles andere als trivial.

Nach einigen Projekten im J2EE Umfeld bin ich inzwischen der Meinung, dass man mit J2EE viel mehr mit irgendwelchen administrativen, verwaltungstechnischen Aufgaben beschaeftigt ist, als mit dem Implementieren von Logik o.ae.

Puh.. ^^

 

[Fats]

Also, auch auf die Gefahr hin, dass ich mir jetzt hier ne Menge Feinde machen koennte...

Ich glaube nicht, daß man sich bei einer sachlichen Argumentation sooo viele Feind machen kann. Ein paar wird es immer geben, aber die würden auch meckern, wenn Du plötzlich niesen würdest Ich denke das Thema ist irre komplex und kann aus entsprechend vielen Perspektiven betrachtet werden. Jede davon ergibt neue Gedanken und Positionen ...

Ich bin selbst schon seit rund 6 Jahren am Rumschwimmen zwischen den ganzen Technolgien (Notes, C, Python, Php, Java, Perl, Flash und Co) und zum Teil etwas ernüchtert. Letztendlich bin ich bei Java gelandet, weil ich einfach gut mit klar kam, es im Gegensatz zum damaligen jungen PHP3/4 definitiv objektorientiert ist, ich BasisKnowHow hatte, die Anschaffungskosten klein sind (in Euro gesehen - Einarbeitungszeit bleibt natürlich immer), halbwegs vernünftige Doku und ebenfalls eine gute Community hat. Man muß sich einfach irgendwann mal für einen Weg entscheiden, sonst bleibt man auf der Kreuzung stehen.

[...] J2EE macht meiner Meinung nach wirklich nur in grossen Grossprojekten Sinn, [...] Nicht falsch verstehen, das gilt wirklich nur fuer J2EE, nicht fuer Java im Allgemeinen. [...] Und genau da springen die Skriptsprachen dieser Welt ein, denn sie sind wesentlich flexibler und mitunter auch einfacher als Java.

Aber wie viel einfacher sind sie wirklich? Das Javakonzept hab ich geblickt, und mit dem Apparat komme ich so halbwegs zurecht. Aber wenn man sich erst in das neue System plus andere basisSprache einarbeiten muß, dann kostet das wieder viel Zeit. Ich habe mir zB. grade Dojo oder Prototype angesehen. Basiert ja letztendlich auf JavaScript - einem alten Bekannten. Aber obwohl JavaScript kein Neuland ist, finde ich es ziemlich nervig, sich da reinzuarbeiten. Funktionalitäten, die man von Java kennt, klappen plötzlich nicht mehr und man beisst sich regelrecht an manchen Stellen die Zähne aus.

Ruby on Rails ist ein ziemlich gutes Beispiel, die Grundideen setzen sich nun zunehmend auch im Java Umfeld durch (zb Grails).

Kannst Du die Grundidee in zwei, drei Sätzen kurz mal anreißen? Ich hab das eine oder andere Mal schon etwas gegooglt und auch n ganzen Haufen gefunden. Aber so richtig klar geworden ist mir das alles noch nicht. OIch dachte, es sei einfach eine eigene Programmiersprache, wie Perl, Pythen - Java. Wenn das Konzept nun auch im Java-Bereich eingesetzt wird, dann muß ja etwas allgemeines drann sein ...

[...] Nach einigen Projekten im J2EE Umfeld bin ich inzwischen der Meinung, dass man mit J2EE viel mehr mit irgendwelchen administrativen, verwaltungstechnischen Aufgaben beschaeftigt ist, als mit dem Implementieren von Logik o.ae.

Aber hilft diese Verwaltung nicht, daß Software stabiler und sicherer wird?

Viele Grüße
Fats

 

[schalentier]

Kannst Du die Grundidee in zwei, drei Sätzen kurz mal anreißen?

Naja, im Grunde gehts um Einfachheit. Soll heissen, die Welt braucht nicht noch ein ultrakomplexes, tolles, featurebepacktes, wollmilcheierlegendes Megaframework, sondern ein einfaches, klares und dynamisches. Es geht um Handling des gesamten Workflows. Bei RoR laed man sich den Ruby Interpreter, gibt ein paar Kommandos ein und hat eine komplette Entwicklungsumgebung. Mit einem weiteren Befehl wird der eingebaute Mini-Server gestartet. Dann nutzt man den Rails-Generator und einen Editor um Quellcode zu erzeugen und zu bearbeiten. Anschliessend drueckt man F5 im Browser und freut sich (oder auch nicht ;-) ). Nebenbei wurden noch Klassen fuer Unit- und Funktionale Tests erstellt, die man nur befuellen muss (Einfachheit!). Damit ist wunderbar Test Driven Development moeglich.

Die API von Rails ist sehr intuitiv (eben einfach), was auch zum Teil an der Sprache (Ruby) liegt. Die Einarbeitungszeit wuerde ich als relativ gering bezeichnen, ein gutes Buch oder Tutorial reicht, um loslegen zu koennen.

Anfangs etwas verwirrend ist die Art, mit Ruby zu entwickeln. So werden verschiedene OOP Prinzipien irgendwie arg verbogen (--> Mixins statt Vererbungsbaeumen), was aber nach und nach klarer und sinnvoller wird. Jedenfalls isses bei mir so (gewesen, muss jetzt erstma wieder mit J2EE kaempfen).

[...] Nach einigen Projekten im J2EE Umfeld bin ich inzwischen der Meinung, dass man mit J2EE viel mehr mit irgendwelchen administrativen, verwaltungstechnischen Aufgaben beschaeftigt ist, als mit dem Implementieren von Logik o.ae.

Aber hilft diese Verwaltung nicht, daß Software stabiler und sicherer wird?

Tja, ist wohl Ansichtssache. Kann sicher sein, aber ich steh' eher auf die besagte Einfachheit. Also nicht alles einstellbar, konfigurierbar und so allgemein machen, wie nur moeglich. Lieber sehr konkret, dafuer einfach und somit nicht nur wartbar, sondern auch austauschbar. Genauso machts RoR vor.

Aber ist alles egal, im Endeffekt zaehlt nur eins: Kann man vernuenftigt Unit-/Funktionale Tests schreiben?

 

[KSG9|sebastian]

Irgendwie habt ihr beide recht.
Ich hab mich auch schon sehr oft mit der Frage "Welches Framework denn nun wieder?" gequält.
Letztendlich gibt es doch ein paar entscheidende Punkte

1) Welche Frameworks kenne ich und mich welchen hab ich gearbeitet?
1.1) Kann ich mit dem Framework das meiste, ohne große Aufwände, erschlagen?

2) Welches Framework wird in der Firma oder im "Bekanntenkreis" eingesetzt? Damit hat man den riesen Vorteil dass man Informationen aus erster Hand bekomment, ebenso Best-Practices um den "Verdammt, das geht so gar nicht"-Effekt so gut wie möglich zu vermeiden.

Wo ich nicht mit übereinstimme ist der Punkt JEE für Großprojekte, denn dein Projekt, speziell die Anzahl an Frameworks wird nur so groß wie der Entwickler es zulässt.
Wenn ich für jedes Miniteil anfange mit Spring IOC, Web 2.0, Struts und JSF u.s.w. dann wird es klar Riesengroß und vor allem verdammt schwer zu warten. Es ist ganz klar das jedes Framework seine Tücken mitbringt, und wenn man diese übersieht dann kracht es halt mal. Wenn ich aber 15 Frameworks hab und die noch irgendwie krude miteinander verstrickt hab, dann ergeben sich nunmal 150 "kleine Fehler" oder noch mehr.

Deshalb ist es imho sinnvoll so wenig wie möglich verschiedene Frameworks zusammenzubringen. Dafür lieber ein paar weniger FWs welche sehr gut geeignet sind.
Beispiel:

Wenn ich eine DAO-Klasse hab dann werd ich mich hüten Spring für IoC einzusetzen. Eine kleine DependencyInjection hab ich schnell selbst mit ner kleinen Propertiesdatei geschrieben. Und das dauert garantiert nicht so lange wie ich für Spring mit allen Tücken brauche. Ebenso hab ich schonmal die Fehlerquelle Spring nicht mit im Projekt.
Und so kann man das endlos weiterspinne. Deshalb: Lieber zwei Wochen mehr für die Entscheidung welches Framework opfern, dafür aber in der Entwicklungs- und Testzeit viel Geld und Nerven sparen.

Gruß Sebastian

 

[psartini]

Ich habe mich bei meinem aktuellen Projekt für Struts 2 entschieden. Und umso tiefer ich einsteige, desto besser gefällt es mir. Ich denke das wird mein Framework der Wahl für künftige Projekte.

Es ist sicher richtig das oftmals die Funktionalität in kleineren Projekten nicht benötigt wird. Allerdings macht es auch keinen Sinn sich für jedes Projekt in ein neues Framework einzuarbeiten. Ich sehe das recht pragmatisch: Man sollte das benutzen was einen am schnellsten/effektivsten zum Ziel führt.

Das ist der Grund wieso ich JSF verworfen habe - ich komme damit einfach nicht klar und in meinem Augen verkompliziert es vieles. Aber das ist sicher Geschmackssache.