studyklar
IProg · Klausur 3 · Aufgabe 9

Bessere Architektur für TEST.JSP: Servlet, DB-Klasse und JSTL

Die Seite aus Aufgabe 8 funktioniert, ist aber schlecht gebaut. Hier geht es um das Warum, um eine bessere Aufteilung und um die neue JSP-Seite. Mit Weiter geht es Schritt für Schritt voran.

Die Aufgabe

9) Architektur (12 Punkte)

a) Warum ist die in der vorhergehenden Aufgabe genutzte Art der JSP-Programmierung nicht empfehlenswert?

b) Skizzieren Sie eine softwaretechnisch deutlich bessere Lösung. – Sie brauchen hier keinen Programmcode anzugeben!

c) Geben Sie nun den zentralen Code der notwendigen JSP-Seiten für Ihre zuvor entwickelte Architektur an.

Architektur heißt hier: Wie verteilt man ein Programm auf Teile, und wer ist wofür zuständig? Gefragt sind drei Dinge:

  • (a) Was an TEST.JSP schlecht ist.
  • (b) Eine bessere Aufteilung, nur als Skizze, ohne Code.
  • (c) Der Code der JSP-Seite in dieser neuen Aufteilung.
Aus Klausur 3, Aufgabe 8 („JSP mit JDBC: Was macht TEST.JSP?“): TEST.JSP speichert eine Eingabe aus dem Formularfeld rem in der Tabelle Rem und zeigt alle bisherigen Nachrichten als Tabelle (REM 1, REM 2, …).
Merke: Jedes Teil eines Programms hat genau eine Aufgabe. Wer etwas ändern will, soll nur an einer Stelle suchen müssen.
  1. Die Schwächen von TEST.JSP benennen.
  2. Modell, Controller und View skizzieren.
  3. Die neue View.jsp Stück für Stück schreiben.

Alles in einer Datei

Keine Trennung von Darstellung, Datenzugriff und Verarbeitungslogik.

TEST.JSP macht drei verschiedene Dinge: Sie zeigt HTML an (Darstellung), sie liest und schreibt die Datenbank (Datenzugriff), und sie entscheidet, ob gespeichert wird (Verarbeitungslogik). Alles steht durcheinander.

Folge: Wer nur das Aussehen ändern will, muss sich durch Java-Code arbeiten. Ein Webdesigner ohne Java-Kenntnisse kann die Seite nicht pflegen. Testen lässt sich die Logik nur zusammen mit der ganzen Seite.

Aus Skript 07, Folie 11: Auf die View-Ebene gehören keine Datenbankzugriffe, keine komplexe Logik und kein Öffnen oder Schließen von Verbindungen.

Fest an die Datenbank gebunden

Hohe Abhängigkeit von der Datenbank: hoher Portierungsaufwand bei DB-Wechsel.

Verbindung und SQL-Text stehen direkt in der Seite. Ändert sich die Datenbank, etwa ein anderer Hersteller oder ein neuer Tabellenname, muss man jede solche Seite anfassen.

Das heißt hoher Portierungsaufwand: viel Arbeit, um das Programm auf eine andere Datenbank umzustellen. Wiederverwenden lässt sich der Zugriff auch nicht: Eine zweite Seite mit denselben Daten bräuchte das SQL noch einmal.

Noch 12 Schritte bis zum Ergebnis
Den ganzen Lösungsweg sehen Studierende und Lehrende der HS KL. Registriere dich mit deiner Adresse @stud.hs-kl.de oder @hs-kl.de, dann geht es hier direkt weiter.
Registrieren

Abbildung 1(a) Schwächen

<html> <body><%  Connection cn = Connection.get_connection();  PreparedStatement ipstmt =          cn.prepareStatement("INSERT INTO Rem(msg) VALUES(?)");  PreparedStatement spstmt =          cn.prepareStatement("SELECT * FROM Rem");   if (request.getParameter("rem") != null) {    ipstmt.setString(1, request.getParameter("rem"));    ipstmt.executeUpdate();  }%>  <h1>Bisher</h1><table><%  ResultSet rset = spstmt.executeQuery ();  int i = 1;  while (rset.next())    out.print ("<tr><td>REM "+ i++ + "</td><td>" +               rset.getString("msg") + "</td></tr>");  cn.close();%>  </table><h1>Ihre Eingabe:</h1>  <form action="TEST.JSP" method="post">    <textarea cols="40" rows="5" name="rem" />    <input type="submit" value="Senden"/>  </form> </body></html>
LegendeTEST.JSP aus Aufgabe 8: HTML, Java und SQL in einer Datei.