MVC Architektur - grundlegendes Verständnis

[oetzi]

Hallo zusammen,

ich möchte gerade mein erstes Webprojekt in MVC Manier erstellen.

Ich denke in der Theorie habe ich MVC verstanden, nur bei der Umsetzung hapert es noch. :roll:

Ich nehme mal als Beispiel eine Registrierung um zu erklären was ich bis jetzt habe und wo ich gerade hänge.


ich habe eine registrieren.jsp (VIEW), die aus einem formular besteht und die eingegebenen daten selber in eine bean_registrieren (Wozu gehört eine bean? MODEL? oder ist sie einfach ein hilfsobjekt?) schreibt.

nach der validierung der eingaben wird ein forward zu einem database - servlet (M?V?C?) gemacht. dieses liest halt die bean aus und speichert sie in der DB ab.

so weit so gut.

wie man wohl schon sieht, fällt mir die zuordnung der einzelnen elemente schwer.
desweiteren fehlt mir ja irgendwie noch komplett der CONTROLLER. da weiß ich gar nicht was ich da wie einsetzen soll. ok, was mir von der theorie her was sagt ist der front-controller. aber ich wüsste nicht wie ich sowas wo unterbringen soll.

Könnte mir bitte jemand helfen und etwas licht ins dunkle bringen?

Vielleicht einfach grob an meinem Beispiel aufskizzieren was wie richtig gemacht wird.

gruß
oetzi

 

[deamon]

Hallo oetzi,

die Zuordnung registrieren.jsp zum V von MVC ist schon mal richtig - das war's dann aber auch schon ;-) Insbesondere sollte eine View nicht selbst Daten ins Modell schreiben, denn das ist Aufgabe des Controllers.

In MVC sähe deine Anwendung also so aus:

V: Formular registrieren.jsp ist die View. Dieses Element ist ein relativ dummer Lückentext, der aber nicht selbst aktiv wird.

M: bean_registrieren ist schon mal ein komischer Name! Wozu brauchst du so ein Objekt? Prinzipiell müsste man das aber dem Modell zuordnen. Typisch wäre eine Bean wie "Kunde", "Nutzer" oder so ähnlich.

C: Der Controller ist die Ablaufsteuerung, die die Anfragen vom Browser annimmt und an die entsprechende Komponente weiterreicht. Der Controller steuert auch, welche Views bei welcher Aktion angezeigt werden. Der Controller übergibt an die View das Modell.

In deinem Beispiel könnte das alles (ganz grob) etwa so aussehen:

public class Benutzer{
  String Name
	String Passwort
	
	public boolean validate(Errors fehlerliste){
		// prüfe Eingaben, z. B. Komplexität des Passwortes
	}
	
	// nach Geschmack Getter und Setter und weitere Logik
}

public class Controller{
	
	Repository repository; // wird von außen gesetzt

  save(HttpServletRequest request){
	  Benuter benutzer = new Benutzer();
		befülleObjekt(benutzer, request);
		Errors fehlerliste = new Errors();
		if(benutzer.validate(fehlerliste)){
			Repository.save(benutzer);
			zeigeView("ok.jsp", benutzer);
		}
		else{
			zeigeView("fehler.jsp", fehlerliste);
		}
	}
	
	delete(HttpServletRequest request){
	  // ...
	}
	
	// ...
}

Gruß
Christian

 

[oetzi]

Hi Christian,
danke schonmal, dass du mir so schnell geantwortet hast.

ich fang mal oben an

ok, die bezeichnung ist vll noch zu überdenken nehmen wir mal bean_nutzer.

Insbesondere sollte eine View nicht selbst Daten ins Modell schreiben, denn das ist Aufgabe des Controllers.

mhh, jetzt habe ich gerade gelernt, dass ich mit

<jsp:useBean id="form_registrieren" class="bean.bean_nutzer" scope="session" /> 
<jsp:setProperty name="form_registrieren" property="*" />

schön alle attribute automatisch in eine bean schreiben kann und jetzt darf ich das nicht...

aber im ernst: genau da hapert es bei mir.
man muss wissen welche möglichkeiten man einsetzen kann, darf, muss bzw. halt nicht, weil es sonst nicht mehr dem MVC entspricht.

1. VIEW: was mache ich jetzt mit meiner view-JSP? lasse ich die daten nicht in die bean schreiben??


2. MODEL: ok, dann habe ich jetzt meine daten in meiner bean_nutzer. wo packe ich am sinnvollsten die entsprechende geschäftslogik zum speichern der daten in der datenbank? direkt mit in die bean?


3. CONTROLLER: tja, in der theorie verstehe ich ja den sinn des controllers, aber die arbeitsweise im detail leider nicht

folgendes verstehe ich:
- ich stelle in der web.xml es so ein, dass alle anfragen an den server erstmal an meinen Controller geleitet werden
- dieser entscheidet dann anhand der URL wohin der request eigentlich gehen sollte und leitet weiter (z.b. bei .../registrieren wird halt zur registrieren.jsp geforwarded)
- so, was ist jetzt der nächste schritt? der user hat seine daten eingegeben und abgesendet. aber wohin geht der request jetzt? ich hätte ja wieder zur registrieren.jsp geleitet und dort die daten in die bean schreiben lassen (weils halt so schön simpel und ohne große arbeit geht ) aber das ist wohl falsch?!? wie macht man das richtig?
- habe ich die daten dann in der bean, könnte der controller die speicher methode der bean aufrufen, so dass der neue user in die DB geschrieben wird.


in deinem code beispiel hast du die speicher logik ja in den controller selbst gepackt. aber ist es nicht eigentlich sinn der sache, dass man einfach nur die speichermethode selbst aufruft ohne zu "wissen" wie/wohin gespeichert wird?!

 

[deamon]

Es ist schon richtig, dass du die View mit einer Klasse verdrahtest, nur sollte die View bei MVC nicht direkt auf das Modell zugreifen. Die Verdrahtung ist nötig, damit die View weiß, von welchem Objekt sie welchen Wert wo einsetzen muss.

Die Logik zum Speichern der Bean ist am besten außerhalb der Bean aufgehoben. Die Metapher ist ein Repository (Lager, Speicher, Ablage), das die Objekte verwaltet. Angenommen du hast ein Objekt der Klasse Artikel, dann würde sich dieses Objekt nicht selbst ins Lager einsortieren, sondern der Controller würde es an das Lager übergeben und bei bedarf auch wieder heraussuchen.

Der Controller nimmt wirklich nur Anfragen an, leitet sie an die passenden Komponenten zur Verarbeitung weiter und wählt schließlich den Lückentext (View) aus, der mit den Modell-Daten ausgefüllt werden soll, wozu er dem Lückentext das Modell-Objekt übergibt.

- ich stelle in der web.xml es so ein, dass alle anfragen an den server erstmal an meinen Controller geleitet werden

Hier wäre das Entwurfsmuster FrontController nützlich, das erstmal alle Anfragen annimmt und dann anhand des URLs entscheidet, welcher Controller aufgerufen werden soll. Dem ausgewählten Controller wird dann die Anfrage übergeben.

- so, was ist jetzt der nächste schritt? der user hat seine daten eingegeben und abgesendet. aber wohin geht der request jetzt?

Du sendest die Daten an die Speichern-Aktion des zuständigen Controllers. Meinetwegen UserController.save().

- habe ich die daten dann in der bean, könnte der controller die speicher methode der bean aufrufen, so dass der neue user in die DB geschrieben wird.

Genau, wobei das Speichern das Repository übernimmt. Prinzipiell könnte man aber auch direkt die entsprechende Methode von Hibernate oder JPA oder ähnlichen Hilfsmitteln verwenden.

aber ist es nicht eigentlich sinn der sache, dass man einfach nur die speichermethode selbst aufruft ohne zu "wissen" wie/wohin gespeichert wird?!

Wohin genau gespeichert wird, ist ja außerhalb des Repositorys unbekannt.

Noch mal ein Beispiel, wie das Speichern eines Objekts komplett ablaufen könnte:

1. Benutzer ruft http://test.com/benutzer/anlegen auf.
2. Der FrontController nimmt die Anfrange an, zerlegt den URL und leitet die Anfrage an die methode anlegen() des BenutzerControllers weiter.
3. Die Methode anlegen() macht nicht mehr, als das Formular zum Client zu schicken.
4. Der Benutzer füllt das Formular aus und schickt es ab an http://test.com/benutzer/speichern.
5. Der FrontController leitet wiederum die Anfrage weiter, diesmal an die Methode speichern des BenutzerControllers.
6. Die Methode speichern des BenutzerControllers erzeugt ein neues Benutzerobjekt, setzt die übergebenen Daten ein, prüft deren Gültigkeit und speichert es im Repository. Abschließend gibt die Methode die View an, die zum Client geschickt wird.

Du könntest dir mal Grails angucken, das vermittelt ein gutes Gefühl für MVC.

 

[oetzi]

morgen,

ich probiere mal etwas technischer zu werden und das ganze nochmal zusammen zufassen, um sicherzustellen, dass ich alles korrekt verstanden habe.

FrontController - Servlet
Aufgabe:
- Annehmen aller Anfragen und weiterleiten an Controller anhand URL
- Hat der FrontController sonst noch eine Aufgabe?

XYContoller - Servlet
Aufgabe:
- die eigentlich steuerung der einzelnen workflows (z.b. speichern)
- ggf. weiterleiten an entsprechenden View

View - JSP
Aufgabe:
- Darstellen von Ergebnissen, welche z.b. vom Controller übergeben worden sind (z.b. in Form einer Bean)
- Einholen von Daten über Formulare

Model - Bean?!?
tja, also beim Model hänge ich irgendwie noch.
siehe unten Punkt 6.x



Ich probiere mal das Beispiel zu erweitern:

1. Benutzer ruft http://test.com/benutzer/anlegen auf.
2. Der FrontController nimmt die Anfrange an, zerlegt den URL und leitet die Anfrage an die methode anlegen() des BenutzerControllers weiter.
2.1 Wie wird das eigentlich techn. realisiert? Gibt es da fertige methoden für?
3. Die Methode anlegen() macht nicht mehr, als das Formular zum Client zu schicken.
3.1 Heißt doch, dass anlegen() ein forward zur registrieren.jsp macht oder?
4. Der Benutzer füllt das Formular aus und schickt es ab an http://test.com/benutzer/speichern.
5. Der FrontController leitet wiederum die Anfrage weiter, diesmal an die Methode speichern des BenutzerControllers.
6. Die Methode speichern des BenutzerControllers erzeugt ein neues Benutzerobjekt, setzt die übergebenen Daten ein, prüft deren Gültigkeit und speichert es im Repository. Abschließend gibt die Methode die View an, die zum Client geschickt wird.
6.1 Daten aus dem ausgefüllten Formular kommen, über den FrontController beim UserController an
6.2 Es wird eine UserBean erstellt und mit den ganzen Daten gefüllt
6.2.1 Ich würde das weiterhin so machen, dass ich ein Forward zur registrieren.jsp mache, dort dann über die Zeile "<jsp:setProperty name="form_registrieren" property="*" />" die Bean automatisch erzeugen und befüllen lassen und dann wieder ein forward zurück zum UserController. Wäre dieses Vorgehen jetzt kompletter Unsinn? Ich kenne im Moment halt keine Alternative zu dem jsp:setProperty. Außer halt komplett alles (erzeugen & befüllen der bean) von Hand zu machen, was aber ja wesentlich mehr arbeit und zudem schlechter wartbar wäre... ich lasse mich gerne eines besseren belehren
6.3 Fehlt noch das eigentliche speichern. Da muss ich sagen, kann ich mir unter der Methaper des "Repository" wenig vorstellen. Wer oder was (Servlet?) übernimmt das speichern? Wie kann ich mir technisch gesehen das von dir genannte Repository vorstellen?

 

[deamon]

Was du geschrieben hast, hört sich so an, als hättest du alles richtig verstanden.

Die Hauptaufgabe des FrontControllers ist die Weiterleitung an die passenden Controller. Zusätzlich könnte man da auch noch andere Themen wie Authentifizierung oder eine globale Fehlerbehandlung (Fehler die nicht "vor Ort" abgefangen werden können) behandeln.

Die Controller müssen übrigens keine Servlets sein, aber die Schnittstelle ist zumindest sehr ähnlich. Der FrontController könnte aber auch die Controller ganz von HTTP entkoppeln und aus dem HTTP-Request parameter heraus lesen und mit denen eine Methode des Controllers aufrufen. Da sind der Fantasie keine grenzen gesetzt. Allerdings fährt man wohl nicht schlecht, wenn man einfach den Request weiterreicht, da der Controller wohl eh ziemlich eng an HTTP gebunden ist und man für eine Desktop-Anwendung eh einen anderen Controller schreiben würde (falls man überhaupt jemals vorhätte, eine Desktop-Anwendung daraus zu machen).

2. Der FrontController nimmt die Anfrange an, zerlegt den URL und leitet die Anfrage an die methode anlegen() des BenutzerControllers weiter.
2.1 Wie wird das eigentlich techn. realisiert? Gibt es da fertige methoden für?

Das ist typischerweise die Aufgabe von Frameworks. Bei Spring MVC gibt es z. B. Klassen zum "HandlerMapping", die genau das machen.

3. Die Methode anlegen() macht nicht mehr, als das Formular zum Client zu schicken.
3.1 Heißt doch, dass anlegen() ein forward zur registrieren.jsp macht oder?

Im Prinzip schon, wobei ich mir nicht ganz sicher bin, was du mit "foward" meinst. Du solltest dem Client keine HTTP 301 oder 302 Nachricht schicken, damit er eine neue Ressource lädt. Wenn er http://test.com/benutzer/anlegen aufruft, sollte im Hintergrund der Controller dafür sorgen, dass die entsprechende JSP-Seite aktiv wird, aber der Nutzer muss davon nichts wissen. Es sollte sich für ihn keine Änderung ergeben, auch wenn du auf FreeMarker-Templates umsteigst (ist ein Blick wert! Ich mag JSP ja nicht so richtig.)

Zum Konvertieren der Strings aus dem Request in Objekte gibt es verschiedene Methoden (ich bin da auch gerade auf der Suche). Eine Möglichkeit bieten z. B. die Apache Commons Bean Utils. Was passiert bei deinem Vorgehen eigentlich mit ungültigen Eingaben?

Das Repository ist aus Sicht der Anwendung der Speicher. Du übergibst dem ein Objekt und das Repository kümmert sich um den Rest. Im Prinzip bieten moderne OR-Mapper aber schon das, was ein Repository ausmacht, so dass du im Controller direkt einer Hibernate-Session oder einem JPA-Entity-Manager das zu speichernde Objekt übergeben kannst. Falls du mit JDBC und SQL arbeiten willst, wäre das Entwurfsmuster DAO für dich interessant. Dann würdest du dem DAO (Data Access Object) das zu speichernde Objekt übergeben und es würde sich um den Rest kümmern, so dass deine Anwendung nicht mit SQL verschandelt wird.

Ich hoffe, ich konnte etwas Erleuchtung geben. Es gibt auch nicht immer genau einen Weg oder eine Wahrheit; es gibt durchaus Varianten von dem, was ich geschrieben habe. Selbst bei MVC gibt es andere Interpretationen.

 

[oetzi]

Was du geschrieben hast, hört sich so an, als hättest du alles richtig verstanden.

Das ist ja schonmal gut!

Das ist typischerweise die Aufgabe von Frameworks. Bei Spring MVC gibt es z. B. Klassen zum "HandlerMapping", die genau das machen.

tja, Frameworks sind so ne Sache.
Da ich noch nie ein Projekt komplett mit JSP, Servlet, Beans, und den vielen anderen Techniken gemacht habe, fehlt mir in den ganzen Bereichen einiges an Erfahrung. So wurde mir schon mehrfach empfohlen das ganze mit Hilfe von Struts zu machen. Ich habe auch bestimmt schon 3-4 verschiedene Struts-Tutorials angefangen. Allerdings stößt man früher oder später (meistens war es früher *g*) auf Probleme. Und da mir halt noch die Erfahrung in den ganzen Grundlagen fehlt, war es mir leider nicht möglich die Probleme mit dem Framework zu lösen.
Darum habe ich mich mittlerweile dazu entschieden erstmal auf Frameworks zu verzichten. Jedenfalls am Anfang. Vll werde ich später mal das ganze in ein Framework portieren. Auch wenn das dann mehr arbeit ist, halte ich es im Moment für sinnvoll.

Im Prinzip schon, wobei ich mir nicht ganz sicher bin, was du mit "foward" meinst. Du solltest dem Client keine HTTP 301 oder 302 Nachricht schicken, damit er eine neue Ressource lädt.

Du meinst doch den Unterschied zw. Forward und Redirect oder? Habe mir den Unterschied eben mal angeguckt. Denke das ich ihn verstanden habe.
Man sollte wohl immer bedenken was bei einem Refresh einer Seite passieren kann/soll.
Ob ich halt einfach intern forwarde oder dem client sage er solle eine andere URL aufrufen (redirecte).

Zum Konvertieren der Strings aus dem Request in Objekte gibt es verschiedene Methoden (ich bin da auch gerade auf der Suche). Eine Möglichkeit bieten z. B. die Apache Commons Bean Utils.

mhh, ich hätte mir ja jetzt einfach z.b. /benutzer_anlegen genommen, das per .equals() verglichen und weitergeleitet.
Oder lohnt es sich dafür wieder eine andere Technik einzusetzen? (Mit dem Hintergrund, dass für mich sowieso alles noch recht neu ist)

Was passiert bei deinem Vorgehen eigentlich mit ungültigen Eingaben?

Wenn die Validierung nicht erfolgreich ist, würde ich halt erneut zur registrieren.jsp weiterleiten, dort die bereitseingegebenen Daten aus der Bean in die Felder laden lassen und irgendwie markieren, wo und was falsch war.

Falls du mit JDBC und SQL arbeiten willst, wäre das Entwurfsmuster DAO für dich interessant. Dann würdest du dem DAO (Data Access Object) das zu speichernde Objekt übergeben und es würde sich um den Rest kümmern, so dass deine Anwendung nicht mit SQL verschandelt wird.

jo hatte vor das ganze erstmal klassisch mit JDBC und SQL zu machen. DAO hab ich schonmal gehört... Werde ich mir mal angucken, ob und in wie weit mir das helfen kann.

Ich hoffe, ich konnte etwas Erleuchtung geben.

Auf jedenfall, vielen Dank für deine Mühe!

Es gibt auch nicht immer genau einen Weg oder eine Wahrheit; es gibt durchaus Varianten von dem, was ich geschrieben habe. Selbst bei MVC gibt es andere Interpretationen.

wohl war und genau das ist es wohl was es am Anfang so schwer macht.

 

[deamon]

tja, Frameworks sind so ne Sache.

Wem sagst du das! Manchmal habe ich das Gefühl, dass die ganzen Frameworks mehr Probleme machen, als sie eigentlich lösen. Besonders kritisch ist die ganze Magie, die in den Frameworks steckt. Die Frameworks von Heute, sind das COBOL von morgen - irgendwann versteht keiner mehr den Code und die Experten aus der Vergangenheit fehlen.

Trotzdem gibt es natürlich Gründe, warum es die ganzen Frameworks gibt. Bei der Web-Entwicklung trifft man immer wieder auf die gleichen Probleme und Lösungen: FrontController, Validierung, Konvertierung, Internationalisierung usw. Bloß dummerweise hat jede Lösung auch irgendwelche Nachteile und meistens sind Frameworks nicht besonders intuitiv und jedes verflogt eine andere Philosophie.

Lange Rede, kurzer Sinn: Ich kann sehr gut verstehen, dass du die Technologien erstmal pur einsetzen möchtest. Da es aber trotzdem nicht schaden könnte, ein paar allgemeine Lösungsansätze zu kennen, wird das Buch "Patterns für Enterprise Application-Architekturen" von Martin Fowler interessant für dich sein.

Du meinst doch den Unterschied zw. Forward und Redirect oder?

Genau. Wie den FrontController im Hintergrund Komponenten auswählt, geht den Client ja nichts an.

Zum Konvertieren der Strings aus dem Request in Objekte gibt es verschiedene Methoden (ich bin da auch gerade auf der Suche). Eine Möglichkeit bieten z. B. die Apache Commons Bean Utils.

mhh, ich hätte mir ja jetzt einfach z.b. /benutzer_anlegen genommen, das per .equals() verglichen und weitergeleitet.

Das meinte ich nicht. Ich meinte wie die Parameter aus dem Request in Eigenschaften eines Objekts übersetzt werden. Nehmen wir an, dass du folgende Klasse hast:

public class Aufgabe{
	private Date fälligkeit;
	private String name;
	private int priorität;
	private Erinnerung erinnerung;
	
	// getter und setter ...
}

Nun empfängt deine Anwendung einen Request, wo Name-Wert-Paare als Strings enthalten sind, schematisch so dargestellt: fälligkeit=2009-02-12&name=Programmieren&priorität=1&benachrichtigung=email&stunden_vor_termin=12
Die Herausforderung besteht nun darin, diese Strings in die entsprechenden Eigenschaften des Aufgaben-Objekts zu übersetzen. Das Datum muss auseinandergenommen und in ein Date-Objekt übersetzt werden. Falls die Anwendung international laufen soll, müssen verschiedene Datenformate berücksichtigt werden! Aus der Priorität muss ein int werden und die letzten Parameter müssen zu einem Erinnerungsobjekt werden, das dann Teil der Aufgabe wird.

jo hatte vor das ganze erstmal klassisch mit JDBC und SQL zu machen. DAO hab ich schonmal gehört...

Es ist mal ganz schön, zu sehen wie es pur geht, aber ansonsten ist das Schreiben von SQL lästig und fehleranfällig. Aber wenn du das trotzdem machen willst, solltest du auf jeden Fall DAOs verwenden. Oder wo wolltest du den SQL-Code lagern? Ich hoffe nicht in den fachlichen Klassen?! Es ist immer gut, technische Aspekte von fachlichen Aspekten zu trennen, sonst kriegt man Probleme, wenn sich die Technik ändert.

 

[oetzi]

also erstmal muss ich dir mal sagen, dass du eine gesunde Objektivität hast! Und das meine ich als Kompliment. Ich habe schon das ein oder andere mal in Foren ähnliche Dinge gefragt und habe oft in kurzen knappen Sätzen gesagt bekommen: "nehme das und das, weil das kann alles und ist überhaupt super" Das bringt nem unerfahrenen reichlich wenig

wird das Buch "Patterns für Enterprise Application-Architekturen" von Martin Fowler interessant für dich sein.

danke für den tipp. Ist notiert

Das meinte ich nicht. Ich meinte wie die Parameter aus dem Request in Eigenschaften eines Objekts übersetzt werden. Nehmen wir an, dass du folgende Klasse hast:

public class Aufgabe{
	private Date fälligkeit;
	private String name;
	private int priorität;
	private Erinnerung erinnerung;
	
	// getter und setter ...
}

Nun empfängt deine Anwendung einen Request, wo Name-Wert-Paare als Strings enthalten sind, schematisch so dargestellt: fälligkeit=2009-02-12&name=Programmieren&priorität=1&benachrichtigung=email&stunden_vor_termin=12
Die Herausforderung besteht nun darin, diese Strings in die entsprechenden Eigenschaften des Aufgaben-Objekts zu übersetzen. Das Datum muss auseinandergenommen und in ein Date-Objekt übersetzt werden. Falls die Anwendung international laufen soll, müssen verschiedene Datenformate berücksichtigt werden! Aus der Priorität muss ein int werden und die letzten Parameter müssen zu einem Erinnerungsobjekt werden, das dann Teil der Aufgabe wird.

jo hatte vor das ganze erstmal klassisch mit JDBC und SQL zu machen. DAO hab ich schonmal gehört...

Ahhh, vll ist gerade der groschen bei mir gefallen
An das was du da erklärt hast, habe ich noch gar nicht gedacht.
So lässt sich dann wohl auch eine bean füllen ohne eine JSP dafür zu verwenden, richtig?

Was ich meinte war ja die reine Weiterleitung anhand der URL. Ich hatte an das offensichtliche, dass die Parameter-Paare ja mitgeschickt werden gar nicht so gedacht...

mhh, aber dazu noch eine Frage:
So:
fälligkeit=2009-02-12&name=Programmieren&priorität=1
sieht ja die URL bei Verwendung der GET Methode aus. Wo verstecken sich eigentlich diese Daten bei der POST Methode? Bzw. wo sie sind ist ja fast egal, aber sind es dabei auch solche Wertpaare und lassen sich damit gleich behandeln?

Es ist mal ganz schön, zu sehen wie es pur geht, aber ansonsten ist das Schreiben von SQL lästig und fehleranfällig. Aber wenn du das trotzdem machen willst, solltest du auf jeden Fall DAOs verwenden. Oder wo wolltest du den SQL-Code lagern? Ich hoffe nicht in den fachlichen Klassen?! Es ist immer gut, technische Aspekte von fachlichen Aspekten zu trennen, sonst kriegt man Probleme, wenn sich die Technik ändert.

Ich bin ja ehrlich ich hätte das schon mit in die Klassen gepackt... Ich kenne bis jetzt halt keine andere Möglichkeit das sauber zu trennen. Ich kann aber voll und ganz verstehen, warum eine Trennung Sinn machen würde. Werde mir dann wohl demnächst mal DAO angucken

 

[deamon]

Zum Befüllen einer Bean braucht man JSP nicht. Prinzipiell könntest du eine ganz normale HTML-Seite mit einem Formular nehmen (nur die Anzeige von Programmausgaben wird dann schwer ;-) ).

Vielleicht entwirrt es deine Gedanken etwas, wenn du dir mal die Vorlagensysteme Velocity oder FreeMarker (ähnlich wie Velocity, aber mit mehr Möglichkeiten) ansiehst. Das sind ganz klassische Vorlagensysteme, die auch nicht auf das Web beschränkt sind.

Ob die Parameter per POST oder GET übergeben werden ist übrigens für den Zugriff auf sie egal. Der läuft immer mit javax.servlet.ServletRequest.getParameter(String name).

Wo ich schon mal mit Buchempfehlungen angefangen habe, lege ich dir noch das ganz allgemeine Buch "Der pragmatische Programmierer" ans Herz. Wirklich sehr lesenswert und unterhaltsam geschrieben.

 

[oetzi]

Zum Befüllen einer Bean braucht man JSP nicht. Prinzipiell könntest du eine ganz normale HTML-Seite mit einem Formular nehmen (nur die Anzeige von Programmausgaben wird dann schwer ;-) ).

das ist mir durchaus bewusst, es ist halt nur wesentlich simpler und viel weniger code wenn ich ne JSP dafür nehme.

Wo ich schon mal mit Buchempfehlungen angefangen habe, lege ich dir noch das ganz allgemeine Buch "Der pragmatische Programmierer" ans Herz. Wirklich sehr lesenswert und unterhaltsam geschrieben.

auch notiert

@deamon: siehe PM

ansonsten käme mir grad noch eine fragen bzgl. der Controller.
Was hat sich als sinnvoll erwiesen? Wonach sollte man die Controller aufteilen?
Ich weiß, dass es ein Stück weit auch Geschmackssache ist, aber da ich keine Erfahrung damit habe frage ich mal

 

[fehlerfinder]

Erstmal ein Riesenkompliment an euch beide - ein echt vorbildlicher Thread, insbesondere für "Sucher", die etwas zum Thema (hier: MVC) wissen wollen.

Ich steig hier mal ein (auch wenn's jetzt schon ein paar Tage zurück liegt):

Im Prinzip schon, wobei ich mir nicht ganz sicher bin, was du mit "foward" meinst. Du solltest dem Client keine HTTP 301 oder 302 Nachricht schicken, damit er eine neue Ressource lädt. Wenn er http://test.com/benutzer/anlegen aufruft, sollte im Hintergrund der Controller dafür sorgen, dass die entsprechende JSP-Seite aktiv wird, aber der Nutzer muss davon nichts wissen. Es sollte sich für ihn keine Änderung ergeben, auch wenn du auf FreeMarker-Templates umsteigst (ist ein Blick wert! Ich mag JSP ja nicht so richtig.)

Ich hätte das jetzt spontan im Controller-Servlet per RequestDispatcher.forward() gemacht - bleibt alles auf dem Server und die Daten kommen trotzdem. Oder liege ich da völlig neben der Spur?

 

[unclesam]

Hi, erstmal kann ich fehlerfinder nur zustimmen was diesen Thread angeht

Trotzdem wollte ich nochmal nachfragen, wie nun in der JSP die Parameter ausgelesen werden.
Werden einfach die request Parameter ausgelesen oder werden die Paramter aus dem Benutzer Objekt verwendet?
Ich tippe mal auf das Benutzer Objekt. Wenn das so ist, wie lese ich die Benutzer Eigenschaften in der JSP ein bzw. greife darauf zu?

 

[fehlerfinder]

Hi, erstmal kann ich fehlerfinder nur zustimmen was diesen Thread angeht

Danke ;-)

Werden einfach die request Parameter ausgelesen oder werden die Paramter aus dem Benutzer Objekt verwendet?

Es geht beides, je nachdem, wo die Daten herkommen. Wenn sie im Request enthalten sind - was bei einem Forward ja z.B. auch immer noch der Fall ist - kannst du mit

request.getParameter("parameter_name");

darauf zugreifen.

Wenn du's über ein Objekt machen willst, verwendest du

<jsp:useBean id="benutzer" type="package.BenutzerBean" scope="request" />
<jsp:getProperty name="benutzer" property="name" />