Oregami Forum

Hi,

ich hab in meinem Fork mal ein paar Änderungen in Sachen Architektur gemacht.

1.) Spring eingebunden, insbesondere für erstmal für Dependecy Injection
2.) DaoManager geschaffen (das direkte Injecten in die Stripes ActionBean hat irgendwie nicht geklappt, daher n Singleton erstmal gemacht, dass die Referenz auf die Daos hält)
3.) OpenEntityManagerInViewFilter hinzugefügt. Nun wird zu Beginn des Requests der EntityManager getriggert und je nach Resource und @Transactional Annotation eine Transaction aufgemacht.

TODO:
4.) Ich würde deutlich lieber eine eigene FilterChain einsetzen, als die Filter der Reihenfolge entsprechend in der web.xml hinzu zu fügen.
5.) Würde gerne Spring benutzen, um properties zu setzen (z.B. für die Datenbank in der Testumgebung/Liveumgebung) - Impl dafür folgt, habe ich gerade keine Zeit für, sollte aber schnell gemacht sein.

Aktuelle Änderungen kann man sich hier anschauen: https://github.com/twendelmuth/oregami. ... 0c99cc85a6

Gerne darf diskutiert werden. Wer es sich anschauen möchte: aktuell funktioniert nur http://localhost:8080/game/1 - die anderen ActionBeans muss ich noch umschreiben.

Spring für DependencyInjection ist super!

DaoManager genauso, über Spring mit Stripes findet man hier noch ein paar Infos, vielleicht helfen die weiter.

OpenEntityManagerInViewFilter für Transaktionierung ist ebenfalls eine schöne Sache, funktioniert das auch mit JUnit-Tests (die wir noch nicht haben)?

Das führt mich auch gleich zu den nächsten Sachen, die wir zentral hinbekommen müssen:

• Datenbankzugriffe sollten aus JUnit-Tests möglich sein. Solche Tests haben wir noch nicht, kommen aber natürlich noch
• wir müssen es hinbekommen, dass die Datenbank-Konfiguration für "Produktion" (öffentlich deployt im Web mit Tomcat) eine andere ist, als für lokale Entwicklungs-Arbeiten. Mein Ansatz, es über ein Maven-Profil hinzubekommen, klappt leider doch nicht wie geplant, denn "Resource-Filtering" funktioniert nicht in Eclipse.
• als lokaler Entwickler kann man ja nicht *nur* mit JUnit-Tests arbeiten, man braucht auch einen Servlet-Container, um "gerenderte" Webseiten anzuzeigen. Du hast eine neue Lösung mit jetty eingebaut, die mir ganz gut gefällt. Dafür muss der Entwickler nur eine Java-Application (org.oregami.Start) starten und benötigt keinen Tomcat-Server mehr. Das vereinfacht die Sache enorm denke ich. Unterschiede zwischen Tomcat und Jetty sind laut meinen Recherchen nicht so relevant, oder? Trotzdem muss auch diese Lösung am besten mit der gleichen Datenbank-Konfiguration laufen wie JUnit-Tests (am besten embedded HSQLDB und der Entwickler muss keine DB-Engine extra starten),

Bekommen wir das Alles hin? Bestimmt, aber wie? Vielleicht kannst du nochmal deine SpringConfig-Lösung darlegen...

gene wrote:Spring für DependencyInjection ist super!
OpenEntityManagerInViewFilter für Transaktionierung ist ebenfalls eine schöne Sache, funktioniert das auch mit JUnit-Tests (die wir noch nicht haben)?

Jain, die Integration Tests würden diese Implementation im @Before bzw. @After selbst machen.

gene wrote: Das führt mich auch gleich zu den nächsten Sachen, die wir zentral hinbekommen müssen:

• Datenbankzugriffe sollten aus JUnit-Tests möglich sein. Solche Tests haben wir noch nicht, kommen aber natürlich noch

Ja ist an sich garkein Problem, wenn sie auch auf die lokale (in memory) Datenbank zugreifen. Wahrscheinlich sind Unit tests erstmal wichtiger als Integration tests?

gene wrote: [*]wir müssen es hinbekommen, dass die Datenbank-Konfiguration für "Produktion" (öffentlich deployt im Web mit Tomcat) eine andere ist, als für lokale Entwicklungs-Arbeiten. Mein Ansatz, es über ein Maven-Profil hinzubekommen, klappt leider doch nicht wie geplant, denn "Resource-Filtering" funktioniert nicht in Eclipse.

Ich werde bis Sonntag sicherlich nochmal dazu kommen und die SpringConfig Variante in meinem Projekt ergänzen. Das kannst du dir dann gerne mal anschauen.

gene wrote: [*]als lokaler Entwickler kann man ja nicht *nur* mit JUnit-Tests arbeiten, man braucht auch einen Servlet-Container, um "gerenderte" Webseiten anzuzeigen. Du hast eine neue Lösung mit jetty eingebaut, die mir ganz gut gefällt. Dafür muss der Entwickler nur eine Java-Application (org.oregami.Start) starten und benötigt keinen Tomcat-Server mehr. Das vereinfacht die Sache enorm denke ich. Unterschiede zwischen Tomcat und Jetty sind laut meinen Recherchen nicht so relevant, oder? Trotzdem muss auch diese Lösung am besten mit der gleichen Datenbank-Konfiguration laufen wie JUnit-Tests (am besten embedded HSQLDB und der Entwickler muss keine DB-Engine extra starten),[/list]
Bekommen wir das Alles hin? Bestimmt, aber wie? Vielleicht kannst du nochmal deine SpringConfig-Lösung darlegen...

Fürs Entwickeln sollte der Jetty erst mal ausreichen. Und damit wäre das ja quasi aktuell schon fertig

PropertyConfig Beispiel ist nun bei mir commited.

Cool, schaue ich mir mal ab!

Du kannst gerne auch im Wiki beschreiben, was du gemacht hast!

Was genau hättest du denn gerne dokumentiert?
Muss man ja erst mal nicht machen, wenn es nicht den Weg in die Hauptapplikation findet

StevenStorm wrote:Was genau hättest du denn gerne dokumentiert?
Muss man ja erst mal nicht machen, wenn es nicht den Weg in die Hauptapplikation findet

Scherzkeks

Ich möchte vermeiden, dass Dinge, die du z.B. einbaust oder eingebaut hast, nirgendwo erklärt sind, so dass sich jeder neue Entwickler das System selbst neu erarbeiten muss.
Gilt natürlich nicht nur für deinen Code sondern für jedermanns Code

Wenn wir die Technik wieder "rund" haben, fange ich mal an, Grundlegendes aufzuschreiben. Weitere Entwickler sollten sich so leicht wie möglich einarbeiten können!

So, ich habe mich in den letzten Tagen etwas besser in das Spring Framework eingelesen. Und das recht erfolgreich.

Daraufhin habe ich unseren Programcode etwas umgestellt, alle Datenzugriffe laufen nun nicht mehr über unsere "DAOs" (Data Access Object), sondern über "Repositories" aus Spring Data JPA. Dadurch sind sehr viele unserer selbst programmierten DAO-Klassen weggefallen, was das Ganze viel schlanker macht.

Außerdem habe ich damit begonnen, für die Web-Anwendungs-Programmierung sog. "Services" zu programmieren - diese Services sollen fachliche Zugriffe auf die Daten zur Verfügung stellen im Gegensatz zum technischen Zugriff über "Repositories" (s.o.).
Beispiel:
Ein fachliches "addUser" prüft, ob der Username und/oder die Mail-Adresse bereits vergeben ist und gibt auch ein fachliches Ergebnis mit entsprechenden Meldungen zurück (bei uns: "ServiceResult" mit "ServiceMessages"), während ein technischer Service eine Datenbank-Fehlermeldung erzeugen würde. Das ist nur ein sehr einfaches Beispiel. Wenn wir die Anforderungen an unsere Anwendung beschreiben, dann meinen wir meist "fachliche Services".

Später sollen dann in die fachlichen Services auch User-Berechtigungen usw. einfließen.

Schön. Conflicted erstmal alles

//EDIT:
ServiceResult - ich hab fast exakt das Selbe gemacht

StevenStorm wrote:Schön. Conflicted erstmal alles

//EDIT:
ServiceResult - ich hab fast exakt das Selbe gemacht

Sorry
Naja, dann sind wir ja immerhin gemeinsam auf dem richtigen Weg!

Ja ich commite gleich mal meine Änderungen... ich hab nebenher Basic Wicket aufgesetzt, ums dir zu zeigen.

Oh, du verwendest Java 7? Die RuntimeException hat in Java 7 einen Konstruktor mehr, der unter Java 6 nch fehlte. Das gab bei mir einen Compile-Fehler.
Lass uns erstmal bei Java 6 bleiben, oder? Wenn ich in Ruhe getestet habe, ob Java 7 auch auf unserem "Produktions-Tomcat" noch läuft...

Nachtrag: Java 7 Code entfernt. deine Änderungen sonst komplett übernommen und Demo-Anwendung neu deployt. Läuft!

Wir müssen dann noch unsere beiden Ansätze "ServiceError" und "ServiceResult" zusammenbringen

Ja lass mal demnächst chatten