Revisionen von Datenbankeinträge wie realisieren?

[flashpixx]

Für mich liegt der Nutzen von Spring darin, mir boilerplate abzunehmen. Und gerade Java ist voll von boilerplate und ceremony code. Spring ersetzt keine Architektur und es hilft auch keine zu erstellen: aber es hilft sie umzusetzen. Gerade Spring-Data (in meinem Fall hauptsächlich JPA) hilft, sich auf das Wesentliche, sprich die Businesslogik zu konzentrieren.

Ich bin den letzten 10 Jahren gerade damit sehr vorsichtig geworden, denn häufig werden genauso argumentiert, dass diese Frameworks eben Arbeit für Boilerplate abnehmen. Wenn man sich aber den Code dann später anschaut sieht man häufig, dass weder die Logik ordentlich ist, noch der Boilerplatecode, oft sieht man, dass die Logik um den Boilerplate Code herum gebaut wurde, weil das Framework eben gewisse Funktionalität, die man braucht, nicht so unterstützt, wie man sie braucht. Gerade bei Java Entwickeln ist der Hang zu unsagbaren komplexen Frameworks mit sehr seltsamen API Strukturen groß. Es wird immer argumentiert, dass man ein OOP Konzept hat, aber wenn man schon einfachste Enums noch über Objekte kapselt oder argumentiert, dass mein Getter / Setter brauchst und alles mittels public / private / proteced machen kann, dann ist dies IMHO am Thema vorbei.

Sauberes und vor allem klares Architekturkonzept ist immer Pflicht, ebenso Refactoring. Wenn man im Konzept die Möglichkeit hat ein Framework zu verwenden, dann muss man auch klar definieren wo die Grenzen des Frameworks sind und was man von dem Framework erwartet (bzw. nicht erwarten kann). Manchmal macht es durchaus Sinn die Funktionalität, die man braucht selbst zu schreiben, da sich der Code dann in die komplette Architektur besser integriert.

@back to topic: Wie man aber in dem Post von pr0gg3r sieht, ist aber genau hier der Punkt. Das Konzept ist schon falsch gewählt, eine andere Technologie wird die Probleme nicht lösen. Ebenso stelle ich mal die konzeptionelle Frage, warum muss man für eine Webanwendung z.B. Java nehmen? Ich brauche ein System wie Tomcat, habe dann evtl noch einen Webserver der als Proxy fungiert, d.h. 2 Serverdienste, die beide Wartung (und damit Kosten) verursachen. Als normler User kann ich nurr begrenzt in die Konfiguration des Tomcat eingreifen. Warum kann man nicht für diesen Fall einen Apache mit PHP verwenden und dann kann jeder User seine Scripte im Homeverzeichnis ablegen und sie werden direkt ausgeführt.

Java selbst hat in den letzten Jahren massive Sicherheitlücken aufgewiesen. Somit für mich keine gute Wahl für Webanwendungen.

Der Ansatz ist saubere Problemdefinition, danach die passende Technologie auswählen und dann umsetzen.

[lilith2k3]

Ich äußere mich dezidiert nicht zu dem Code. Nur soviel: Bevor man daran denkt, welche Technik zum Einsatz kommt, sollte man sich über sein Modell Gedanken machen. Hier scheint einiges nicht so wirklich durchdacht zu sein. Und in der Tat würde ein Framework den Grad an Strukturlosigkeit noch steigern.

Gerade bei Java Entwickeln ist der Hang zu unsagbaren komplexen Frameworks mit sehr seltsamen API Strukturen groß.

Onion code: it has many layers and makes you cry.

Gerade bei Java Entwickeln ist der Hang zu unsagbaren komplexen Frameworks mit sehr seltsamen API Strukturen groß.

Oh ja. Ehe man sich's versieht, hat einen das Teil hier verschluckt: SimpleBeanFactoryAwareAspectInstanceFactory (Spring Framework API 2.0)

Ich sehe vorallem 3 Kernpunkte im Einsatz von Spring:

1) Dependency Injection

Spring übernimmt das komplette Wiring up. Ich bestimme die benötigten Komponenten, ohne mich selbst um deren Wiring kümmern zu müssen.

2) Spring MVC bietet mir einen Front-Controller samt Routing-Möglichkeiten. In den Cotrollern definiere ich die Ressourcen, die erreichbar sind, seien es HTML-Dokumente, SOAP-Endpunkte oder REST-Schnittstellen.

3) Spring Data JPA erlaubt es mir, meine Domänenobjekte durch Annotationen persistierbar zu machen. Im simpelsten Anwendungsfall definiere ich lediglich ein Repository-Interface, wo ich die Interaktion mit der Datenbank e.g. per Query-Methods erledigen lassen kann:

findAllOrdernumberLike(String ordernumber)

Per Reflection erledigt Spring den Rest. In dem Fall nimmt mir Spring sogar die Arbeit ab, "stumpfes" SQL schreiben zu müssen.

Alles kann, nichts muss. Natürlich gibt es immer noch die Möglichkeiten per JDBC-Template und prepared Statements selbst Hand anzulegen - was sich bei hinreichend komplexen Anwendungsfällen anbietet. Aber viel CRUD-Code bleibt einem einfach erspart.

Das sind die Sachen mit denen auch der 08/15 Javashop zu tun hat. Dass es darüberhinaus Spring Integration, Sping Batch, Spring AMQP, Spring Securtiy gibt, braucht ihn nicht unbedingt zu interessieren.

Ein sehr guter Architektur-Vortrag von Onkel Bob:

[pr0gg3r]

Das was Du machst ist für mich "ganz übles Coding", das ich eher einem Azubi noch zugestehe.

Ich bin ja auch noch Azubi

Wenn ich den Code sehe, dann zeigt das für mich, dass Du nicht wirklich verstanden hast wie OOP funktioniert, siehe Prinzipien der OOP insbesondere Kapselung und Abstraktion sind bei Dir nicht erkennbar, denn Du mischst Strukturen.

Ich verstehe ehrlich gesagt nicht ganz genau, warum du das denkst. Ich habe das eigentlich ziemlich abstrakt gemacht. Ich habe eine Oberklasse mit den Membern "name", "label", "isRequired" usw., die schließlich jedes Feld hat. Davon leite ich die anderen Felder ab, diese haben dann nur noch die zusätzlichen Methoden für die spezifischen Dinge. Außerdem habe ich es ja auch gekapselt. Ich habe ja zB die Methode GetHTMLForm(), diese gibt das Formular aus. So kann ich jedes Feld*.getHTMLForm(), ohne mich darum kümmern zu müssen, was in der Methode tatsächlich passiert. Also wenn man dann mal absieht, dass ich die Ausgabe nicht von der Logik trenne (zB über die von dir vorgeschlagenen Renderklasse), habe ich das doch mit ganz ordentlichem OOP gemacht? Natürlich kann ich das auch in eine Renderklasse packen (Renderer.render(Field field)) und dann je nach Objekt die enstprechenden Methoden (((FieldInt) Field.getMin());, field.getLabel(), ...) aufrufen. Vielleicht war nicht ganz klar, was ich mit "den häufig verwendeten Datentypen von MySQL" wirklich meine. Es geht darum, dass mir MySQL bestimmte Datentypen zur Verfügung stellt, mit denen ich meine Tabellen abbilden muss, da ich meine Spalten nur mit diesen Typen deklarieren kann. Deswegen bilde ich diese in meinem Programm ab. Ich sage nicht, jedes Feld hat einen maximalen und einen minimalen Wert (Generalisierung), sondern ich sage, nur ein Feld für einen Integer kann einen maximalen und minimalen Wert haben.

Im Grunde ist es bei Dir eine funktionale Programmierung, die Du mit OOP versucht hast auf zu hübschen. Sorry für die harte Kritik, aber ohne ein sinnvolles Architekturkonzept mit entsprechendem OOP-Design wirst Du immer Probleme haben. Du solltest erstmal bei den Designfragen beginnen und erst danach die Technologie auszuwählen.

Ich wüsste jetzt ehrlich gesagt nicht, wie ich das prozedural wenig umständlich umsetzen könnte.

[flashpixx]

Ich habe das eigentlich ziemlich abstrakt gemacht. Ich habe eine Oberklasse mit den Membern "name", "label", "isRequired" usw., die schließlich jedes Feld hat.

Nein Du hast nicht abstrakt gearbeitet, denn Dinge "isRequired" gehören in die Datenbank (not null) oder wenn sie im der Darstellung verwendet werden, in den View des MVC Pattern. Du hast hier etwas undefiniertes gebaut und zusätzlich sind die Namenskonventionen schlecht gewählt, denn wenn eine Variable "DBTable" nennt, dann ist das die physische Verbindung zu der Datenbanktabelle und hat mit der Ausgabe nicht zu tun (MVC Pattern wäre das dann das Modell).

Davon leite ich die anderen Felder ab, diese haben dann nur noch die zusätzlichen Methoden für die spezifischen Dinge. Außerdem habe ich es ja auch gekapselt. Ich habe ja zB die Methode GetHTMLForm(), diese gibt das Formular aus. So kann ich jedes Feld*.getHTMLForm(), ohne mich darum kümmern zu müssen, was in der Methode tatsächlich passiert.

s.o. das ist nicht Sache des Feldes sondern des Views.

Also wenn man dann mal absieht, dass ich die Ausgabe nicht von der Logik trenne (zB über die von dir vorgeschlagenen Renderklasse), habe ich das doch mit ganz ordentlichem OOP gemacht? Natürlich kann ich das auch in eine Renderklasse packen (Renderer.render(Field field)) und dann je nach Objekt die enstprechenden Methoden (((FieldInt) Field.getMin());, field.getLabel(), ...) aufrufen.

Nein, die Überprüfung von min / max Werten macht mittels Check-Constraints auf der Datenbank, d.h. das Modell kann bei falschen Eingaben eine Exception werfen oder man kann innerhalb des Controllers diese Überprüfung machen. Beides hast Du nicht gemacht.

Es geht darum, dass mir MySQL bestimmte Datentypen zur Verfügung stellt, mit denen ich meine Tabellen abbilden muss, da ich meine Spalten nur mit diesen Typen deklarieren kann.

Und was hat das mit dem problem zu tun, die Typenconfertierung zwischen Datenbank und Java geschieht mittels JDBC bzw. Prepare-Statements, somit wird ein Javatyp direkt auf den dazu passenden mySQL Datentyp gemappt (vice versa). Das was Du da machst, ist überflüssig, da es direkt von der Architektur geliefert wird.

Dein Architektur ist ineffizient und nicht sauber gekapselt und letzteres ist definitiv ein Kriterium für OOP.

[pr0gg3r]

Hallo flasgpixx,

Nein, die Überprüfung von min / max Werten macht mittels Check-Constraints auf der Datenbank, d.h. das Modell kann bei falschen Eingaben eine Exception werfen oder man kann innerhalb des Controllers diese Überprüfung machen. Beides hast Du nicht gemacht.

danke nochmal für deine Ausführliche Antwort. Ich denke, ich habe es nun verstanden.

Eine Frage hätte ich noch: Angenommen, ich mache eine Validierung über Check-Constraints, wie kann ich dann von meiner View darauf zugreifen, also feststellen, welche Werte gültig sind? Da es sich um eine HTML-Applikation handelt, möchte ich zB mit jQuery das Formular vorab validieren, also dem Benutzer anzeigen, welche Felder nicht korrekt ausgefüllt sind und zwar ohne, dass ich die Daten an die Datenbank sende und Fehler abfange.

[pr0gg3r]

Habe es herausgefunden, ich komme über das information_schema an den CONSTRAINT_NAME dran.