JDBC - SQL anweisungen im java Code?

[Jack]

Hallo,

ich beschäftige mich seit Kurzem mit JDBC und mir ist (negativ) aufgefallen, dass in vielen Beispielen der SQL Code in den Java Code als String verarbeitet wurde. Ich frage mich nun ob dies die übliche Vorgehensweise ist, den SQL Code einfach so unterzumischen, oder ob es andere Techniken gibt den SQL Code sinnvoll vom Java Code zu trennen?

Ich währe auch dankbar darüber, wenn jemand wissen würde wie man den SQL Code programmtechnisch sinnvoll auslagert!

Weiterhin frage ich mich immer wieder ob es sinnvoll ist durch den statischen SQL Code in einer Anwendung das Datenbankdesign mit dem Java Code fast untrennbar zu verknüpfen!

Vielen Dank!

 

[squeaker]

Man lagert ihn am sinnvollsten als String aus. SQL wird im Klartext an den Server geschickt und dort interpretiert. Ihn vorher hin eine andere Form bringen ist eher hinderlich.

Du kannst natürlich deine einzelnen SQL-Statements noch in eine XML-Datei packen. Ist aber mehr Aufwand als nötig. Häufig wirst du auch auch Eingabemasken SQL-Statements generieren. Dann sind es sowieso nur Schipsel die du hast und die können dann ruhig in eine Klasse eingebettet sein, die aus der Eingabe ein passendes SQL-Statement verfasst und dann an den Server schickt.
Wenn du eine sinnvolle Anwendung schreiben willst, wird der SQL-Code eben nicht statisch sein. Schon im einfachen select from where wirst du auf unterschiedliche Tabellen zugreifen, Felder darstellen oder Weglassen, Evtl. nur die Anzahl der Elemente ausgeben usw. alles gesteuert von einer GUI. Und nur ein SELECT auszulagern in eine Datei ist ein wenig albern. Aber du kannst natürlich die Generierung der einzelnen Statements in eine SQL-Statement-Klasse auslagern. Dann hast du alles beisammen und der Code bleibt wartbar.

 

[Vincentius]

Hallo Jack,

ab einer bestimmten Projektgröße, ist es sinnvoll, auf die EJB zurückzugreifen. Wenn Du das auch noch über Container Managed Persistence löst, brauchst Du Dich um den SQL Code gar nicht mehr zu kümmern.

 

[Christian Fein]

Original geschrieben von Vincentius
Hallo Jack,

ab einer bestimmten Projektgröße, ist es sinnvoll, auf die EJB zurückzugreifen. Wenn Du das auch noch über Container Managed Persistence löst, brauchst Du Dich um den SQL Code gar nicht mehr zu kümmern.

Da tuts auch ein O/R Mapper wie Hibernate, oder standardisiert wie JDO.

Anlaufstelle: http://www.jpox.org

 

[Valentin-]

Zumal O/R Mapper bald in EJBs integriert werden....was auch immer
das bedeutet.....

 

[Jack]

EJB

Vielen Dank erstmal!

Von JDO hab ich schon mal was gehört! Leider hab ich es noch nie angewendet, muss ich mich mal schlau machen!

Zu dem EJB: Was meinst du damit konkret? Einen EJB entwickeln, der mit JDO arbeitet? Und was meinst du mit "Container Managed Persistence"?

Ich hab leider noch sehr sehr wenig Erfahrung mit J2EE!

 

[Thomas Darimont]

Hallo!

Hallo Jack,

ab einer bestimmten Projektgröße, ist es sinnvoll, auf die EJB zurückzugreifen. Wenn Du das auch noch über Container Managed Persistence löst, brauchst Du Dich um den SQL Code gar nicht mehr zu kümmern.

Stimmt schon... jedoch hast du mit EJB-QL noch LANGE nicht die Möglichkeiten die du mit normalem SQL hast ... zb.Bsp sind bestimmte Aggregatfunktionen nicht verfügbar, komplexere Joins sind eine Qual und lange Zeit konnte man noch nicht einmal angeben in welcher Sortierung man die Daten haben will ... Gott sei dank bieten Manche EJB Container die Möglichkeit Native SQL Statements unterzuschieben...

http://www.theserverside.com/discussions/thread.tss?thread_id=16531
Gruß Tom

 

[Jack]

aha, danke


ich blick da jetzt etwas klarer druch (auch wenn ich noch viel lernen muss)!