SqlObject - eine objektorientierte Art SQL-Statements zu schreiben.

[scaphare]

Hallo Miteinander,

ich habe ein Paket geschrieben, mit dem SQL Statements geschrieben werden können. Und zwar objektorientiert.
Per Adapter können die Ausgaben unterschiedlichen Bedürfnissen angepasst werden.
Unten habe ich mal einen Auszug aus meinem Eclipse-Projekt angehängt.

Die Main-Klasse enthält ein Beispiel, um die Funktionsweise aufzuzeigen.
Das Sql-Paket ist von mir so angelegt, dass die Statements fließend geschrieben werden können.
Der vorliegende Auszug unterstützt MySQL und SQLite. Ich habe desweiteren Adapter geschrieben, um Jasper Reports - oder iText - Ausgaben zu erzeugen. Aus exemplarischen Gründen habe ich nur den Adapter ConsoleTable beigefügt, um die Funktionsweise zu verdeutlichen.

Falls die Beispielausgaben nicht erzeugt werden, dann fehlt wohl die sqlitejdbc Bibliothek.
Die kann hier heruntergeladen werden.

Bitte schreibt mir, ob es sinnvoll ist, diesen Entwicklungspfad weiterzuverfolgen.
Ich bitte, um konstruktive Kritik, die sich konzeptionell mit der Thematik auseinandersetzt.

Zum Download von SqlObject

(Programmiertechnische Anmerkungen bitte ich zurückzustellen, da es sich hier um einen ersten Prototypen handelt.)


Ein Beispiel:

package anywheresoftware.b4a.tsqlobject;

import java.security.SecureRandom;
import java.math.BigInteger;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;

import anywheresoftware.b4a.inspector.inspect.*;

import anywheresoftware.b4a.tadapter.*;
import anywheresoftware.b4a.BA.ShortName;

@ShortName("Main")
public class Main {

	public static void main(String[] args) throws Exception {

		Config.getInstance().register("connection.default", "jdbc:sqlite:data/migli.db");
		Config.getInstance().register("connection.driver", "org.sqlite.JDBC");
		
		String str = new BigInteger(130, new SecureRandom()).toString(4);
		String str2 = new BigInteger(130, new SecureRandom()).toString(8);
		
		DateFormat df = new SimpleDateFormat("yyyy-MM-dd H:m:s");
		Date today = Calendar.getInstance().getTime();
		String CreatedAt = df.format(today);
		
		SqlInsert ins = new SqlInsert();
		ins.into("users");
		ins.column("user_name").value("tsc" + str);
		ins.column("user_pass").value("pw"+str2);
		ins.column("is_active").value(1);
		ins.column("is_deleted").value(0);
		ins.column("created_at").value(CreatedAt);
		
		try {		
			System.out.println(ins.Execute());
		} catch(Exception e) {
			e.printStackTrace();			
		}
		
		
		SqlSelect s = new SqlSelect();
		s.from("users");
		
		try {
			System.out.println(s.toString());
			System.out.println(s.Execute().save(new ConsoleTable()));
			
		} catch (Exception e) {
			e.printStackTrace();
		}
	    
	}

}

 

[turtle]

Zunächst finde ich es bemerkenswert wie Du dir Gedanken über eine objekt-orientierte Schale zum Absenden von SQL-kommandos gemacht hast. Der Code sieht auch ganz gut und lesbar aus.

Aber...

Bitte schreibt mir, ob es sinnvoll ist, diesen Entwicklungspfad weiterzuverfolgen.

Da bin ich leider anderer Ansicht. Dieses "Problem" wurde bereits mehrmals in sehr guter Manier in verschiedenen Frameworks eingesetzt. Die eine Linie von O/R-Mapper geht von der Annahme aus, dass der Entwickler von SQL-Kommandos nichts (bzw. wenig) zu sehen bekommt und dieses vom Framework erledigt werden soll. Zu dieser Philiosophie zählen zum Beispiel Hibernate oder JPA.

Eine weitere Linie versucht die Benutzung von SQL-Kommandos zu vereinfachen. Hierzu zählt besipielsweise mein Lieblings-Framework myBATIS. Bei diesem ist der Vorteil, entgegen zu Deinem Ansatz, dass der SQL-Befehl praktisch unverändert angewendet werden kann und die Ergebnisse (Resultset) auf Java-Objekte gemapped werden können. Dieses ist aus meiner Erfahrung ein guter Ansatz, weil Leute, die sich mit DB besser auskennen (als ich) eigentlich immer auf SQL-Ebene denken und reden. Dein Ansatz dagegen ist scheint mir ein Zwitter zu sein, denn weder ein DBA noch ein Java-Kenner sehen das SQL-Kommando, das da abgesetzt werden soll, direkt. Hier sehe ich noch Potential, dass Du zum Beispiel im Bereich Logging etwas tun könntest.

Daher sehe ich wenig Gründe, warum ich Deinem Ansatz folgen sollte, denn wie gesagt, ich sehe das SQL-Kommando erst zur Laufzeit, schlecht für Diskussionen mit DBA's, und zum Optimieren muss ich Java-Code schreiben und ändern.

 

[mvitz]

Die Frage ist auch, welche Vorteile deine Library gegenüber ausgereiften Lösungen hat, die dasselbe Ziel haben.

jOOQ - jOOQ : A peace treaty between SQL and Java
Querydsl

Die Arbeit, die du dir bisher gemacht hast, ist mit Sicherheit gut gewesen, alleine für das eigene Verstädnniss, die Frage ist eben nur, ob neben diesem Lerneffekt es jetzt noch Sinn macht, viel Energie in etwas zu stecken, wo es eben schon ausgereifte Lösungen gibt. (Ganz im Sinne von: "Don't reinvent the wheel.") Die Antwort kannst allerdings nur du selbst dir geben.

 

[scaphare]

Danke! Ich kannte diese Bibliothek nicht! Witzig! Diese verfolgt einen analogen Ansatz!

 

[ARadauer]

Muss mich meinen Vorrednern anschließen.. schaut nett aus.. du bist aber nicht der erste der sich darüber Gedanken gemacht hat... wenn man sich ansieht wie weit zb schon spring data jpa ist, würd ich da nicht mehr viel Engergie investieren...