J2EE Architektur/Pattern/...

[Sempah]

Hallo zusammen,

ich hätte generelle Fragen zu einem WebProject. Zu aller erst was es können sollte:

- Präsentation via Browser (HTML/JSP/... ?)
- Bereitstellung von Applikationsweiten Instanzen von bestimmten Klassen, wie Beispielweise eine Datenbankverbindung. Wie könnte man es lösen, dass man einmalig eine Datenbankverbindungsinstanz erzeugt und diese innerhalb der kompl. Anwendung verwendet?
- LDAP Funktionalitäten sollten integriert werden
- ...

- welche Technik würde sich eignen (simple java/servlets/jsp?, ejb?, ...?)
- welches Framework würde sich eignen? (beim Framework wäre es mir wichtig, dass es gut dokumentiert, ohne viel Schnick Schnack über wenige Schritte konfigurierbar, ...)

Mfg Sempah

 

[maki]

Du fragst nach den grundlegenden Dingen die eine J2EE WebApp beherrschen sollte, da kann man alles empfehlen

Über die alte (und schon in vielen Dingen überholte) Standard J2EE Architektur bist du dir bewusst?
Core J2EE Patterns: Patterns index page

Ist halt ein klassisches Schichtenmodell..

Jedenfalls solltest du Spring imho in Erwägung ziehen, lohnt sich und ist den Standards in vielen Dingen überlegen.

 

[Sempah]

Über die alte (und schon in vielen Dingen überholte) Standard J2EE Architektur bist du dir bewusst?

Deshalb frage ich ja gerade. Versucht man nach möglichen Architekturmodellen zu googlen, wird man einfach von Informationen und Möglichkeiten überschüttet.
Da ich aber noch nicht wirklich lange im Business bin, kann ich schlecht differenzieren, was davon alt und überholt ist, was davon aktuell als eine Art Standard angesehen wird, was davon Zukunft hat.

Grundsätzlich wäre mir die Architektur egal (müsste mich ich ehh einarbeiten).
Möchte nur nicht auf Basis veralteter Technologien etwas entwickeln und am Ende erfahren, dass man es so in der Art und Weise vor 10 Jahren realisiert hat.

Spring habe ich mir auch schonmal angeschaut, besonders da es in Zusammenhang mit OSGi Möglichkeiten bietet.
Aber genau das ist es ja was ich meine: Ich könnte rein statische Servlets/JSP erstellen, ein Framework (auf bspw. MVC) benutzen, mit EJB arbeiten, OSGi mit einbringen oder oder oder

Falls sich irgendwann mal etwas herauskristallieren würde, wäre ich über Literaturempfehlungen nicht abgeneigt.

 

[maki]

Glückwunsch, du bescheibst das Problem von J(2)EE: zuviele Optionen

Literaturempfehlungen? klar, zu welchem Thema denn? Oder möchtest du überschüttet werden?

Musst dich schon entscheiden, aber nicht verzweifeln, dauert Jahre bis man weiss wo es langgeht, deswegen am Anfang lieber KISS nehmen, was aber Frameworks nicht ausschliesst.

 

[Sempah]

Aber vlt kann man von den vielen Optionen, einen Großteil von Anfang an ausschließen

Entscheiden kann ich mich ja erst wenn ich alle Alternativen kenne (bzw. Erfahrungen/Tipps bekomme).
In meiner "Unwissenheit" würde ich jetzt mit JSP<-->Framework(Struts/Spring,...) beginnen.

KISS? oO

 

[maki]

Gute Wahl imho

KISS = Keep It Simple & Stupid

 

[Sempah]

und ich google schon nach Kiss im Zusammenhang mit Java ...
Naja vielen Dank mal wieder. Mal schauen inwiefern mich das weiter bringt.

 

[byte]

heisst das nicht keep it simple sexy?

 

[tfa]

ne, nur "Keep it simple, stupid!" - da ist kein "&".

 

[maki]

Hast mal wieder recht tfa!

 

[tfa]

Manche sagen auch Keep it simple and stupid. Aber das find ich falsch. Es ist ja nicht stupid, nur weil es simpel ist. Sondern man ist ein Dummkopf, wenn man es nicht simpel hält.

 

[ps]

Wenn du Webanwendungen bauen möchtest solltest du dir ein Framework zulegen das du beherrschen lernst. Andere kannst du dir anschauen... aber es ist wie mit allem. Mit "seinem" Framework ist man immer am produktivsten.

Meine Empfehlung derzeit: Tapestry 5. Wenn es actionbasiert sein soll dann Struts2.

Wenn es etwas heavier sein darf eventuell Seam und JSF. Allerdings finde ich das der Vorteil (viele Komponenten vorhanden) dadurch aufgehoben wird das es mühselig ist diese auf seine Bedürfnisse anzupassen oder gar neue zu erstellen. Wird mit JSF 2.0 ja vielleicht alles besser. We will see.

Für das Backend häng alles sehr von den Anforderungen ab. Manchmal verwende ich nur tapestry-ioc (hier beliebigen DI Container einfügen) um meine Domain zusammenzuschweissen und Services bereitzustellen. Manchmal muss es aber dann doch ein EJB3 Backend sein.

Da ich derzeit eine sehr große Webanwendungen baue, weiche ich immer weiter vom "JEE Stack" ab... ich überlege zB. seit geraumer Zeit die SQL Datenbank zu kicken und fange an die Persistenz neuer Module auf HBase auszulegen (-> Welcome to Apache Hadoop! ).

Wie überall: es gibt keine Patentrezepte. Einen Tipp darf ich allerdings geben: Egal was man baut, versuchen möglichst Technologieunabhängig zu sein und seine Domain nicht mit Infrastruktur Code verschmutzen schadet nie. Das hilft enorm eine gute Architektur zu finden.