nicht angemeldet
Hallo,
- Ich arbeite ungerne mit HTML und CSS, kann ich das irgendwie umgehen? Ich würde die Seiten viel lieber per Zusammenklicken oder java Code erstellen, aber ich glaube das geht nicht…
Da fiele mir zum Beispiel GWT ein, dass das mW erlauben soll. Da ich aber persönlich lieber näher an HTML arbeite halte ich von solchen Frameworks eher Abstand. Der Standard-Spring-Weg über Thymeleaf wäre daher meine Wahl.
- Ich muss gucken wie ich die HTMl Dinger UnitTeste
Wenn du HTML selber schreibst (auch, wenn du Komponentenbibliotheken wie JSF u.ä. verwendest) willst du keinen Unit-Test dafür schreiben. Ich würde dir empfehlen, einen GUI-Test (mit Mock-Backend oder als Integrationstest mit echten Backends) zu schreiben. Ansatzpunkte bzw. Stichworte: Selenium (wenn du mehrere Browser nutzen willst) oder du nimmst deinen bevorzugten Browser in der "headless"-Variante (z.B. bei firefox, chrome verfügbar). Dann programmierst du die Interaktionen des Benutzers mit der Seite und testest, ob nach den Interaktionen entsprechende Informationen in der GUI zu sehen sind.
Ich rate dir hier aber, dass du nicht zu viel auf einmal lernst. Schau erstmal, dass du ordentliche Unit-Tests schreibst. GUI-Tests sind dann nochmal ein ganz neues Thema.
- Wie würdet ihr an so ein Projekt herangehen? Angenommen ich wäre Hobbygärtner, dann könnte man sagen, dass ich mir gerne einen englischen teppichrasen heranzüchten würde, qualität ist mir entsprechend wichtiger als zeit und mühe.
Es kommt sicher darauf an, in welchem Umfeld du es verwenden willst. Beruflich verwenden wir in meiner Firma viel Liferay, eine professionelle Portal-Lösung - davon gibt es auch eine Open-Source-Variante. Die nimmt dir das ganze Benutzerhandling, E-Mail-Validierung usw natürlich sofort ab und du kannst dich in die Portlet-Programmierung stürzen. Ist aber auch etwas gewöhnungsbedürftig. Ansonsten ist dein Ansatz über Spring schon nichtmal schlecht.
Bis auf deine Auswahl von eclipse. Ich lese im anderen Thread, dass du Student bist - hole dir ASAP eine Studentenlizenz von IDEA IntelliJ und steig um. Das wird dir schon mittelfristig dutzende Stunden Konfiguration von eclipse (oder, wie ich es nenne, Schrottlipse) sparen.
- Was haltet ihr von der Wahl der technologien? Gibts da besseres?
Wenn du im Java-Umfeld bleiben willst, sehe ich nur drei relevante Optionen, insb. wenn du das auch als Vorbereitung für dein Berufsleben nutzen willst: Spring und JEE als die großen Enterprise-Java-Webframeworks und Liferay als "fertige" Portal-Lösung.
- UML Diagramme haben mir in der Vergangenheit nicht soviel gebracht wie ich mir gewünscht hätte, würdet ihr an meiner stelle einen Softwareplan erstellen bevor ihr anfangt zu coden? Falls ja, wie würdet ihr diesen bauen? Und mit welchen Technologien?
Ich bin kein UML-Fan. Ein paar grobe Skizzen für die Architektur sind aber hilfreich. Wichtig sind:
- welche Komponenten will/kann/muss ich verwenden, wie sind diese verbunden? Datenbank, User-Store, Application Server, …
- Welche User-Gruppen/-Rollen gibt es, welche Use-Cases nutzen sie (ein klassisches Use-Case-Diagramm).
- ER-Diagramm ist hilfreich. Wenn es komplizierter wird aber nicht ein Diagramm für die ganze DB, sondern domainenbezogene kleinere.
- Wie Definiere ich welche Module sinnvoll wären? Und Kapsle ich den Code per Api-Server-Client Architektur oder macht das wenig Sinn, weil ich die ganze Anwendung besser als ein Module definieren sollte? Je mehr Module ich hab desto beschissener wird es den Code zu implementieren, weil ich dann Kreuz und Quer durch die Module klicken muss... andererseits wäre es besser die richtigen Module sofoert anzulegen als später per Refactoring zu modularisieren... könnt ihr mir hierzu ein paar Tipps geben?
Ich würde mal mit zwei Modulen starten:
- Frontend
- Business-Logik
Deine Business-Logik teilt sich dann in folgende Teile:
- eine Boundary. Hier machst du pro use-case eine Methode rein. Das Frontend darf nur Methoden aus der Boundary aufrufen. Die Boundary darf nur Methoden aus dem BL-Logik aufrufen (nicht aus der Boundary). Aufgabe der Boundary ist insb. der Transaktionsabschluss.
- Business-Logik. Hier gibt es zwei Varianten: Anemic Design und DDD. Im Anemic-Design machst du kleine Entity-Klassen ohne eigene Logik (deine Entities sind also nur Getter/Setter). Die Logik kommt dann in *Service-Klassen, welche die Entities dann passend bearbeiten. Das ist vielerorts gängige Praxis, hat aber den Ruf einer bad practice. Die Alternative DDD bedeutet, dass deine Entities Logik beinhalten. Service-Klassen schreibst du nur noch für Infrastruktur-Aufgaben.
- Entities (im Falle von Anemic Design) und Repositories sind etwas näher an der DB dran.
Generell empfehle ich dir, deinen Code nach inhaltlichen und nicht nach strukturellen Erwägungen zu sortieren. D.h. deine packages sind nicht "controller", "entities", ... sondern zum Beispiel "userregistration", "userconfirmation", … In vielen Tutorials sieht man es leider anders, aber das halte ich für Murks.
Der Vorteil des separaten BL-Moduls ist, dass du hier später noch ein API-Modul draufsetzen kannst, wenn du z.B. eine Single-Page-App bauen willt und ein ReST-Frontend brauchst.
Viele Grüße Matti