T400 Technische System-Architektur

[gene]

In diesem Thread soll über die technische Architektur unseres Systems diskutiert werden. Es geht hier also wirklich um die Programmierung der Server-Anwendung (also Nix was im Browser, sondern das, was die Inhalte für den Browser erzeugt) und die Speicherung der Daten in einer Datenbank.


Meine Vorstellungen sind derzeit die folgenden:
Ich möchte die Server-Anwendung mit Java programmieren. Ich verwende Java täglich im Beruf und bilde mir daher ein, mich dort auszukennen.
Eine mögliche Alternative wäre PHP, dort kenne ich mich auch etwas aus, bin dort aber seit mehreren Jahren nicht mehr auf dem aktuellen Stand (Objektorientierung usw.). Java erscheint mir die "professionellere" Lösung als PHP zu sein.

Für die Java-Server-Anwendung möchte ich als Web-Framework gerne das Stripes-Framework verwenden. Ich habe darüber einige positive Dinge gehört und mich auch schon eingelesen im entsprechenden Buch des Framework-Erschaffers. Das Framework nimmt einem Einiges bei der Programmierung ab, ist aber gleichzeitig noch recht überschaubar und nicht so "fett" wie z.B. "Java Server Faces". Es bietet Unterstützung z.B. zu wiederverwendbaren Layouts (Templates), Mehrsprachigkeit, Validierung von Formulareingaben mit einheitlichen Fehlerausgaben u.v.m. und ist dabei ohne großen Konfigurationsaufwand einsetzbar.

Welches Java-Framework zur Speicherung ich verwenden möchte ist für mich noch nicht entschieden. Ich denke da z.B. an Hibernate mit JPA, auch dafür habe ich mir bereits das passende Buch angeschafft.

Kann sich hier noch jemand zu diesem Thema äußern?

[VedekSVE]

Kann sich hier noch jemand zu diesem Thema äußern?

Na klar, nur ob es der Diskussion dienlich ist, bezweifle ich.

[jojoschi]

Und der Java-Code erzeugt dann HTML-Seiten? Oder wie kann man sich das vorstellen.
Ich würde eher für PHP&SQL plädieren. Wer weiß was Oracle noch mit Java in den nächsten Jahren anstellt (Lizenzgebühren?).

[gene]

...
Ich würde eher für PHP&SQL plädieren.

Ich habe mir natürlich auch schon länger Gedanken darüber gemacht, ob wir Java oder PHP verwenden sollen.
Kurze "Vorwarnung": Ich bin mit meinen Kenntnissen bei der PHP-Programmierung bei PHP 4 stehengeblieben und kann PHP nicht "aktuell" in allen Standards einsetzen. Java verwende ich täglich im Beruf und bin daher dort eher auf dem aktuellen Entwicklungsstand.

Tatsache ist wohl: Man kann komplexe Webanwendungen sowohl mit PHP als auch mit Java erstellen. PHP ist mittlerweile in der Objektorientierung weit fortgeschritten und daher in dem Bereich Java wohl "ebenbürtig". Das Argument "PHP ist eine prozedurale und damit rückständige Programmiersprache" fällt somit weg. Man muss daher noch etwas genauer hinsehen, um eine Entscheidung oder Hilfestellungen dafür zu bekommen.

Eine gute Zusammenfassung der Argumente findet man in diesem PDF-Dokument:
http://www.cs.montana.edu/~tosun/phpvsjava.pdf
Dort findet man einige technische Dinge, die Java hat und die PHP nicht hat.

Klar, in PHP kann man sich schneller einarbeiten, es ist einfacher zu erlernen. Aber andersherum könnte man auch meinen: Wer Java programmieren kann (und das ist meistens beruflich bedingt, weil Java eher in großen Firmen-Projekten eingesetzt wird), der hat meistens mehr Hang zu vernünftigen Software-Architekturen und zu vernünftigen Programmiermustern. Das bedeutet natürlich nicht, dass man auch in PHP vernünftig programmieren kann. Klar kann man das.
Versteht mich nicht falsch, es geht hier nicht um "subjektiv gutes Programmieren". Mir geht es hier darum, dass unser System eine Architektur besitzt, die das System gut wartbar, gut erweiterbar, gut verstehbar usw. macht. Das kann man auf jeden Fall mit Java erreichen.

Ganz direkt und für jeden verstehbar finde ich folgende Argumente mitentscheidend für Java gegenüber PHP:

• Es gibt für Java definitiv mehr stabile Entwicklungs-Umgebungen
• Debugging ist in eigentlich jeder Java-Entwicklungsumgebung möglich - in PHP meines Wissens nach nicht so einfach.

Wenn Java und PHP sonst gleichwertig wären, würden alleine diese beiden Argumente ausreichen, Java zu präferieren.

Wer weiß was Oracle noch mit Java in den nächsten Jahren anstellt (Lizenzgebühren?).

Ich kann mir bei bestem Willen nicht vorstellen, dass Oracle irgendwann mal Lizenzgebühren für Java erheben wird.

Java ist sicher eine gute Wahl. Welche Hardware wird denn zur Verfügung stehen? Bei den Servern, die man bei den Hostern üblicherweise bekommt, könnte es - je nach Komplexität des Systems (ich kenne Stripes nicht) - durchaus Performanceengpässe geben, denn leichtgewichtig ist es ja nicht gerade

Kultpower und TheLegacy laufen momentan auf einem gemeinsamen Server - der nichts Anderes zu tun hat, der also vollständig für diese beiden Domains zur Verfügung steht. Der Server kostet 69 Euro im Monat und ist eine "fette Kiste" (Quadcore CPU, 12 GB Speicher) - was aber nicht heißt, dass wir sofort mit so einem dicken Server beginnen müssen. Aber mit so einer Maschine sollte es meiner Meinung nach erstmal kein Problem sein, eine Java-Webanwendung inkl. Datenbank zu hosten. Ein "Webhosting-Paket" wird für unser Projekt nicht ausreichen, man sollte auf jeden Fall von einem eigenen Server ausgehen.
Alles Weitere nach oben (mehrere Server falls zuviel Last) wäre auch für mich neu - aber bis wir dahin kommen, dass ein solcher Server nicht ausreicht, wird es meiner Meinung nach erstmal etwas dauern
Stripes ist eher als "leichtgewichtig" anzusehen, denn vermutlich brauchen wir dafür gar keinen Java-Server, der die JEE-Spezifikation erfüllt, sondern es würde vermutlich z.B. auch ein Tomcat-Server ausreichen.

Was die OR-Mapping-Schicht angeht, so habe ich in verschiedenen Projekten gute Erfahrungen mit iBatis gemacht (http://ibatis.apache.org, guter Abstract unter http://de.wikipedia.org/wiki/IBATIS). Nicht die eierlegende Wollmilchsau wie Hibernate, aber dafür leichtgewichtig und erheblich einfacher zu warten

Habe mir das mal angesehen, es scheint wirklich etwas "weniger" zu können als z.B. Hibernate. Ich würde es erstmal mit Hibernate nach dem JPA-Standard versuchen, dafür habe ich mir auch das Buch "JPA mit Hibernate" gekauft und arbeite das gerade durch. Parallel arbeite ich ich in Stripes ein, und zwar mit diesem Buch.

[MZ per X]

Klar, in PHP kann man sich schneller einarbeiten, es ist einfacher zu erlernen. Aber andersherum könnte man auch meinen: Wer Java programmieren kann (und das ist meistens beruflich bedingt, weil Java eher in großen Firmen-Projekten eingesetzt wird), der hat meistens mehr Hang zu vernünftigen Software-Architekturen und zu vernünftigen Programmiermustern.

Ich bin ja immer der, der den Finger hebt und die Zukunft des Projekts anmahnt. Deswegen möchte ich hier nochmal darauf hinweisen, dass wir später hoffentlich zu dem Punkt kommen wollen, an dem die Community irgendwie die Programmierung/Wartung des Systems übernimmt. Das wäre natürlich leichter zu erreichen, wenn die Einstiegshürden nicht so hoch sind, wenn also die Wahl unserer grundlegenden Technik nicht von vornherein zuviele Leute ausschließt.

Ich habe natürlich keine Ahnung, inwieweit hier Java einen Nachteil darstellt, ich wollte es einfach nochmal zur Diskussion gestellt haben. Ansonsten halte ich mich als blutiger Laie natürlich raus.

[gene]

... möchte ich hier nochmal darauf hinweisen, dass wir später hoffentlich zu dem Punkt kommen wollen, an dem die Community irgendwie die Programmierung/Wartung des Systems übernimmt. Das wäre natürlich leichter zu erreichen, wenn die Einstiegshürden nicht so hoch sind, wenn also die Wahl unserer grundlegenden Technik nicht von vornherein zuviele Leute ausschließt.

Ich bin trotz deines Hinweises nach wie vor der Meinung, dass wir mit Java eine sehr gute Software-Architektur mit erprobten Mitteln hinbekommen können. Die Tatsache, dass Java-Programmierer etwas schwieriger zu finden sind als PHP-Programmierer, nehme ich dafür gerne in Kauf. Wenn wir zwei gescheite Java-Programmierer finden, die langfristig mitmachen, dann ist das vielleicht sogar besser als 15 PHP-Programmierer.

Meine konkreten Argumente findet ihr oben...

[wingi]

Ich bin kein Java-Fan, für im Sinne der Wartbarkeit ist ein Java-Projekt aber Ok. Die deutliche Trennung von Ausgabe (HTML-Templates + CSS), Funktionalität (Java) und Datenbasis (Datenbank) hält dann wieder mehr Möglichkeiten, HTML-Designer und Entwickler Aufgaben zu verteilen.

Gruß,

Christian.

[StevenStorm]

Ist die Entscheidung, dass kein Spring benutzt wird denn in Stein gemeiselt?
Ich halte es für extrem sinnvoll zumindest die Dependency Injection von Spring zu benutzen. Zudem gibts noch einige andere nützliche Sachen z.B. OpenSessionInViewFilter (aktuell wird für jedes Datenbank Statement eine Transaction geöffnet, wenn ich das richtig gesehen habe?)

Zudem sollte darauf geachtet werden, dass man nicht Testklassen mit Business Logik mischt. (MonkeyIsland.java z.B.)
Außerdem wäre es noch sinnvoll, wenn man eine allgemeine Formater Einstellung festlegt + alle darauf einschärft diese zu benutzen.

[gene]

Ist die Entscheidung, dass kein Spring benutzt wird denn in Stein gemeiselt?
Ich halte es für extrem sinnvoll zumindest die Dependency Injection von Spring zu benutzen. Zudem gibts noch einige andere nützliche Sachen z.B. OpenSessionInViewFilter (aktuell wird für jedes Datenbank Statement eine Transaction geöffnet, wenn ich das richtig gesehen habe?)

Ist natürlich Nichts in Stein gemeißelt, wir sind ja noch in einer sehr frühen Phase. Und bislang habe ich ja den Java-Code alleine "verbrochen", und ich kenne ja auch nicht Alles
Dependency Injection von Spring finde ich OK, bin ich aber bislang noch kein Experte drin.
Bisher habe ich mich erstmal darauf konzentriert, mit JPA/Hibernate unser aktuelles Datenmodell abzubilden, so dass ich Daten in eine Datenbank speichern kann, laden kann und auf einer Webseite anzeigen kann. Mehr nicht. Transaktionssteuerung ist gerade erst am Anfang, d.h. für eine "echte" Web-Anwendung muss man da eh noch gründlich ran.

Was hast du denn bislang alles mit Java gemacht? Hat du viel Erfahrung mit Web-Anwendungen? Beruflich?

Zudem sollte darauf geachtet werden, dass man nicht Testklassen mit Business Logik mischt. (MonkeyIsland.java z.B.)

Die drei Klassen MonkeyIsland.java, ResidentEvil.java und XWing.java sind nur als Start gedacht, um ohne Eingabe-Oberfläche reproduzierbar Daten in die Datenbank zu bekommen. Die Klassen fallen natürlich irgendwann wieder weg.

Ist die Entscheidung, dass kein Spring benutzt wird denn in Stein gemeiselt?
Außerdem wäre es noch sinnvoll, wenn man eine allgemeine Formater Einstellung festlegt + alle darauf einschärft diese zu benutzen.

Sinnvolle Idee. Welche Möglichkeiten gibt es, bestimmte Formatierungsmuster "vorzugeben", so dass das auch technisch unterstützt wird? Und dann auch noch für unterschiedliche Entwicklungsumgebungen?

[StevenStorm]

Ist natürlich Nichts in Stein gemeißelt, wir sind ja noch in einer sehr frühen Phase. Und bislang habe ich ja den Java-Code alleine "verbrochen", und ich kenne ja auch nicht Alles
Dependency Injection von Spring finde ich OK, bin ich aber bislang noch kein Experte drin.
Bisher habe ich mich erstmal darauf konzentriert, mit JPA/Hibernate unser aktuelles Datenmodell abzubilden, so dass ich Daten in eine Datenbank speichern kann, laden kann und auf einer Webseite anzeigen kann. Mehr nicht. Transaktionssteuerung ist gerade erst am Anfang, d.h. für eine "echte" Web-Anwendung muss man da eh noch gründlich ran.

Was hast du denn bislang alles mit Java gemacht? Hat du viel Erfahrung mit Web-Anwendungen? Beruflich?

Ja ich sehe das frühe Stadium - habe ja auch schon auf Github geforged und mir nen Überblick verschafft
Ich bin beruflich als Java Entwickler tätig bzw aktuell halb Java Entwickler, halb Teamleiter.

Zudem sollte darauf geachtet werden, dass man nicht Testklassen mit Business Logik mischt. (MonkeyIsland.java z.B.)

Die drei Klassen MonkeyIsland.java, ResidentEvil.java und XWing.java sind nur als Start gedacht, um ohne Eingabe-Oberfläche reproduzierbar Daten in die Datenbank zu bekommen. Die Klassen fallen natürlich irgendwann wieder weg.

Ich habe nichts gegen das testweise befüllen von einer Datenbank - nur sollte das auch im Test Context geschehen.

Ist die Entscheidung, dass kein Spring benutzt wird denn in Stein gemeiselt?
Außerdem wäre es noch sinnvoll, wenn man eine allgemeine Formater Einstellung festlegt + alle darauf einschärft diese zu benutzen.

Sinnvolle Idee. Welche Möglichkeiten gibt es, bestimmte Formatierungsmuster "vorzugeben", so dass das auch technisch unterstützt wird? Und dann auch noch für unterschiedliche Entwicklungsumgebungen?

Genau sagen kann ich es dir leider nur bei eclipse. Da kann man xml files importieren für Styling. Netbeans, IntelliJ etc werden soetwas aber zu 100% auch haben.