JDBC , JDO oder JPA

[cipherwar]

Hallo,

ich will eine Anwendung schreiben, die einige Daten aus einer DB holt und dann in einer Jtable darstellen soll.

Das ganze ist relativ klein und übersichtlich, eine 1-user-Anwendung.

Würdet ihr für sowas in der Anwendung JPA oder JDO einsetzen oder lediglich ein bischen JDBC in der GUI einbauen?

Ich bin mir nicht sicher, ob ich mit JPA nicht massiv overhead einbaue ...

 

[ARadauer]

relative klein und übersichtlich... jdbc reicht...

 

[cipherwar]

Danke. Dennoch Modelklassen einführen oder direkt in den Gui-Klassen?

(Es soll so eine Art todo-Liste sein, die dann in einer jtable dargestellt werden.)

 

[ARadauer]

Ich würd immer Model Klassen machen. Da kannst du dir dann auch ein sauberes Table Model schreiben das von AbstractTable Model erbt...

 

[turtle]

Klein und übersichtlich, da muss myBATIS erwähnt werden

 

[cipherwar]

myBatis sieht interessant aus, allerdings auch recht unbekannt. Da stellt sich die Frage, ob sowas auch in 2 Jahren noch weiterentwickelt wird....

Gibt es ähnliches auch von Apache oder so?

Ansonsten werde ich es mir mal ansehen.

 

[maki]

iBatis bzw. jetzt myBatis gibt es seit über 10 jahren und es wird auch in den nächsten jahren nicht verschwinden... nebenbei, myBatis ist 2010 von Apache wieder "weggezogen"

 

[cipherwar]

Interessanter Hinweis. Was ist mit Hibernate? Kanone für Spatzen?

 

[Andgalf]

Interessanter Hinweis. Was ist mit Hibernate? Kanone für Spatzen?

Jup ist es. Ist ja eine JPA Implementierung.

 

[maki]

Gegenfrage: Was kannst du denn bereits?

JDBC?
myBatis?
Hibernate/JPA?

Wenn du 3 mal "nein" antwortest, wäre zu Übungszwecken JDBC nicht so verkehrt.

 

[cipherwar]

JDBC.
Ich frage mich nur, ob es wirklich so gut ist (wie bislang), in meiner Gui-Klasse die JDBC-Statements "reinzubasteln" .. Das ist ja dann in keinster Weise mehr MVC.

Also dachte ich, es wäre sinnvoll Modellklassen zu haben, die das machen und die dann mit der Jtable in meiner Gui-Klasse zu verbinden. Und so kommt dann die Frage auf, ob meine Modellklassen dann nicht sowas wie JPA oder myBatis verwenden sollten.

 

[cipherwar]

Also vielleicht mal ganz konkret:
Ich habe eine SqLite-DB mit den Datenbanken

CREATE TABLE [options] (
[userName] VARCHAR(100)  NOT NULL,
[userId] INTEGER  NOT NULL PRIMARY KEY,
[userLicence] VARCHAR(100)  NULL,
[userEmail] VARCHAR(100)  NULL,
[programEditor] VARCHAR(250)  NULL,
[programEmailer] VARCHAR(250)  NULL,
[programBackupDir] VARCHAR(250)  NULL,
[pserAmazonPid] VARCHAR(100)  NULL
)

und

CREATE TABLE [users] (
[id] int  NOT NULL,
[loginname] varchar (45)  NULL,
[prename] varchar (45)  NULL,
[surname] varchar (45)  NULL,
[email] varchar (45)  NULL,
[password] varchar (45)  NULL,
[registered] TIMESTAMP  NULL,
[lastlogin] TIMESTAMP  NULL,
[activated] BOOLEAN  NULL,
[created] TIMESTAMP  NULL,
[modified] TIMESTAMP  NULL
)

und

CREATE TABLE [searches] (
[id] int  NOT NULL PRIMARY KEY,
[user_id] int  NOT NULL,
[phrase] varchar ( 100 )  NOT NULL,
[responses] TEXT  NULL,
[lastactive] TIMESTAMP DEFAULT 'NULL' NULL,
[active] int DEFAULT 'NULL' NULL,
[runcount] int DEFAULT 'NULL' NULL,
[vendor_id] int  NOT NULL,
[created] TIMESTAMP DEFAULT 'NULL' NULL,
[modified] TIMESTAMP DEFAULT 'NULL' NULL
)

Die Options möchte ich beim Start der Anwendung einlesen. Fertig. Dafür würde ich nur JDBC nehmen, eigene Klassen sind m.E. schon Oversized.

Die Users : Hier brauche ich CRUD.
Die Searches: Hier ebenfalls CRUD.

Ich denke, ich muss Entity-Classes für User + Searches machen (Model) und die dann zur Darstellung in der Jtable (View) verwenden. Der Weg dazu ist mir allerdings nicht klar - die letzte DB-Entwicklung habe ich ca. 2005 gemacht, und seitdem hat sich ja einiges getan (s.o.).

Also: nun mit Entity-Klassen + myBatis + TableModel und dann Jtable?

 

[turtle]

Entity-Klassen + myBatis + TableModel und dann Jtable?

Ja.

Bei myBATIS sind Entity-Klassen normale POJO's und fungieren bei mir immer als DTO's.

Also bei Deinem Beispiel:

public class Users {
	int id;
	String loginname;
	String prename;
	String surname;
	String email;
	String password;
	Timestamp registered;
	Timestamp lastlogin;
	boolean activated;
	Timestamp created;
	Timestamp modified;
        // getter und setter für die Attribute
}

Dann würde ich eine DAO-Klasse schreiben, die mir die CRUD-Operationen anbietet und diese auf entsprechende SQL-Kommandos von myBATIS laufen lassen.

Für die GUI würde ich, wie bereits angemerkt, ein TableModel schreiben, dass die Entity-Klassen verwendet.

 

[cipherwar]

Danke für das Beispiel, das hilft mir schon mal weiter.

Nochmal eine kurze Nachfrage:

dann würde ich eine DAO-Klasse schreiben, die mir die CRUD-Operationen anbietet

Ich verstehe das so, dass diese EINE DAO-Klasse dann die Entity-Klassen einsetzt. Damit ist diese DAO-Klasse dann also eine Art Controller-Klasse, ja?


In dem oben genannten Beispiel für MyBatis fehlt diese DAO Klasse aber: http://www.java-forum.org/blogs/turtle/162-mybatis.html

Die MyBatis-Doku gibt auch nichts dergleichen her: MyBatis 3 | Getting started

Sowas ist soweit ich das sehe aber hier beschrieben: The IdleWorx Blog: mybatis.

Ist das in der Art, wie Du mir empfiehlst?

 

[turtle]

Ja, genau, eine DAO-Klasse kann als Controller für die Persistenz verstanden werden und kapselt die Persistenz-Einzelheiten weg von der Applikation, die sich darum nicht kümmern muss.

Die DAO-Klassen sind seit einiger Zeit nicht mehr Bestandteil von myBATIS, unter anderem deshalb, weil diese leicht selbst geschrieben werden können. Im Prinzip ist Dein Link ein guter Anfang. Ich würde "nur" darauf achten, dass ich wirklich ein Business-Interface definieren würde, um dann spezifisch darauf eine myBATIS-Implementierung zu entwickeln. Dabei wäre mir wichtig meinen Applikationscode frei von SQL-spezifischen (oder myBATIS) Exceptions zu halten, weil dies Dein Restcode abhängig von der Persistenzschicht macht.

Und wenn Du wirklich Deinen Applikationscode gegen das DAO-Interface entwickelst, kannst Du später die Implementierung tauschen gegen eine, die Dir vielleicht besser gefällt (JPA oder Hibernate), obwohl ich mir das bei myBATIS nicht vorstellen kann

 

[cipherwar]

Gut, werde ich drauf achten. Inzwischen habe ich schon die Konfiguration von MyBatis hinbekommen - war zwar einiges ziemlich mies dokumentiert, aber immerhin läufts nach knapp 2 Stunden.

Vielen Dank!

 

[cipherwar]

ich muss doch nochmal nachfragen...

eine DAO Klasse? Oder eine pro Entity-Klasse?

Ich habe mir auch mal den DAO Generator unter
DaoGen - Data Access Object Code Generator
angesehen. :rtfm: Der würde je Entity-Klasse eine Dao-Klasse erzeugen.

Wenn ich MyBatis richtig verstanden habe, müsste ich dann die MyBatis-Funktionalität in diesen DAO packen, ja?

 

[turtle]

Ich würde je Entity-Klasse eine Dao-Klasse schreiben.

Weil aber die Funktionalität, die in einem DAO gepackt werden soll, sehr vom Programm, Anforderungen, Datenbank, Tabellen-Struktur abhängig ist, gibt es hier keine Empfehlung, die immer passt. Oft sind im DAO CRUD-Funktionen drin. Insbesondere mehrere komplexe SELECT-Anfragen werden oft in mehrere Interface-Methoden rausgereicht und nicht nur eine Read-Methode. Bei einem sauberen Design kann man aber ziemlich einfach anfangen und bei Bedarf erweitern.

MyBatis-Funktionalität in diesen DAO packen

Genau.