Swing Baut die View die Modelebene auf oder wer?

[Rudolf]

Moinchen,

ich versuche ein Programm nach dem MVC zu bauen. Man soll ja Model von View trennen. Nun ist meine View ein Formular und die Model besteht aus drei Klassen, die jeweils Inhalte der Formulare erstellen. D.h. es wird ein Student, ein Business und ein Rating-Objekt erstellt, die jeweils Daten vom Formular haben.

Jetzt frage ich mich natürlich was echtes MVC bedeutet. Erstellt die View die jeweiligen Objekte aus dem Model, oder ist es eher MVC wenn die ganzen Strings an die Model übergeben werden und diese baut dann die Objekte zusammen. Für ein relativ großes Formular müsste man viele String Referenzen an eine Funktion übergeben. Das ist auch nicht schön.

Welche Vorgehensweise ist optimal?

 

[JavaProfi]

Grundsätzlich gehört IMO die ganze Geschäftslogik in den Controller.
Von der Geschäftslogik zu trennen sind Funktionalitäten, welche die Datenintegrität sicherstellen.
Diese gehören IMO in die Methoden des Models.
Die Manipulation der Daten im Model erfolgt ausschließlich über die Schnittstellen-Methoden des Models (z.B. getter- und setter-Methoden). Demnach würde ich Methoden zum Erzeugen und Entfernen von Objekten ebenso in das Model packen, denn die Objekte müssen ja sauber in die Datenstruktur (z. B. eine LinkedList) des Modells "eingehängt" werden. Das Anstoßen der Methoden zum Erzeugen der Objekte des Datenmodells erfolgt dann wiederum aus dem Controller heraus.

Die View beobachtet das Model. Eine View liest nur Daten aus dem Model, wenn das Model die View über Datenänderungen, die die View betreffen benachrichtigt. Das bedeutet, du benötigst in der View eine Funktionalität die auf notify()-Aufrufe des Models reagiert und aus der update()-Methode des Views angestoßen wird.

Der Controller reagiert auf die UserEvents und greift schreibend und lesend auf das Datenmodell zu. Der Controller beinhaltet IMO daher die Listener-Klassen (ich realisiere diese i.d.R. als innere Klassen, aber das ist sicher Geschmacksache) manipuliert die Daten im Datenmodell einerseits und manipuliert das "Verhalten" der GUI andererseits.
Unter Verhalten meine ich z.B. ob Komponenten enabled oder visible sind usw.

Wer baut das Model auf?
Nun ja, ich halte es in der Regel so, dass ich zuerst das Model (z. B. in der main-Methode der Applikation) instanziere. Dann instanziere ich die View und übergebe dem Konstruktor eine Referenz auf das Model. Als letztes instanziere ich den Controller und übergebe dem Konstruktor des Controllers Referenzen auf das Model und View.

Gruß
JP

 

[Rudolf]

Erstmal danke für deinen ausführlichen Beitrag, aber ich bin mir unsicher, ob der Kern des Problems deutlich geworden ist. Ich habe daher ein kleines Codebeispiel programmiert, das das Problem verdeutlichen soll. Für die Erklärungen sind auf die Kommentare im Code zu achten.

import java.util.HashSet;
import java.util.Set;

import javax.swing.JPanel;
import javax.swing.JTextField;


public class MVC {
	public static void main(final String[] args) {
		new Controller();
	}
}

class Controller {
	public Controller() {
		final Model model = new Model();
		final View view = new View(model);
		model.register(view);
	}
}

class Model {
	Set<Observer> ovservers = new HashSet<>();

	public void register(final View view) {
		ovservers.add(view);

	}

	void notfiyObs(final Event event) {
		for (final Observer o : ovservers) {
			o.update(event);
		}
	}

	public void handle(final String text1, final String text2) {
		final Student student = new Student(text1);
		final Business business = new Business(text2);
	}

	public void handle(final Student student, final Business business) {
		// TODO Auto-generated method stub

	}

}

class Student {

	public Student(final String text) {
		// TODO Auto-generated constructor stub
	}

}

class Business {

	public Business(final String text) {
		// TODO Auto-generated constructor stub
	}

}
class View implements Observer {
	final JTextField field1 = new JTextField();
	final JTextField field2 = new JTextField();
	final Model model;

	public View(final Model model) {
		this.model = model;
		final JPanel panel = new JPanel();
		panel.add(field1);
		panel.add(field2);

		userInput();
		userSubmit();
	}

	private void userSubmit() {
		// user betätigt submit
		// entweder baut die view die model struktur selber wie folgend:
		final Student student = new Student(field1.getText());
		final Business business = new Business(field2.getText());
		model.handle(student, business);

		// oder er übergibt die stringreferenzen an eine model funktion wie
		// folgt:
		model.handle(field1.getText(), field2.getText());

		// auf den ersten blick wirkt die zweite veriante geeigneter für echtes
		// mvc. der nachteil tritt auf, wenn die die anzahl der zu übergebenden
		// referenzen eine entsprechende größer erreichen.

	}

	private void userInput() {
		// user gibt daten ein
		field1.setText("Eignabe1");
		field2.setText("Eignabe2");
	}

	@Override
	public void update(final Event event) {
		event.accept(new Visitor() {
		});
	}
}

interface Observer {
	void update(Event event);
}

interface Event {

	void accept(Visitor visitor);

}

interface Visitor {

}

Ist das sowas in der Art, wie du es dir vorgestellt hast, JavaProfi?

 

[GUI-Programmer]

Ich kann dir mal hiermit behilflich sein. Dein Code will ich jetzt mal nicht beurteilen, aber er beinhaltet auf jeden Fall die nötigen Klassen (Oberserver, ...).

 

[Rudolf]

Hallo GUI-Programmer,

danke für dein Beispiel.

Ohne dich angreifen zu wollen, finde ich dein Beispiel etwas merkwürdig. MVC bedeutet nach meinem Verständnis das hier: Datei:ModelViewControllerDiagram2.svg ? Wikipedia

Bei dir hat man ein Mix. Bei dir erstellt eine Klasse Main die Views und ein Model. Der Controller kennt nur die Model und die View kennt Model und Controller.

Nach meinem Verständnis erstellt aber der Controller die Views und das Model. Er ist der einzige der direkte Referenzen dazu hat und nicht die View. Die Model muss daher ein Observee sein, das über notify die Observer über Veränderungen in der Model-Ebene benachrichtigt.

Aber das bedeutet alles nichts, dass ich recht habe und du unrecht. Kannst du mir bitte erklären warum du der Meinung bist, dass dein Bespiel echtes MVC ist?

 

[GUI-Programmer]

Mal vorweg: Dies soll jetzt bitte keine Diskussion über MVC werden

Denn es gibt sehr viele unterschiedliche Interpretationen / Umsetzungen / Möglichkeiten der Implementierung. Eine riesige Diskussion gab es schonmal eben wegen bERt0r Umsetzung von MVC (Kannst ja mal eine Google oder Forumsuche nach "MVC bERt0r" starten!!)

Eine andere Art der Umsetzung, die ich vorwiegend einsetzte: Minimal MVC Example aus meiner Signatur

 

[Rudolf]

Ich suche aber nach einem optimalen MVC, das meinem Codebeispiel genugtund ist.

Das Problem an beiden MVC Beispielen von dir ist, dass die actionPerform in den Controller ausgelagert ist. Aber was ist, wenn in der Methode von actionPerform viele Referenzen aus der View verarbeitet werden? In deinen Beispielen passiert ja nicht unbedingt viel und man braucht nicht viele Referenzen aus der View, aber was ist wenn doch, z.b. es werden Inhalte aus einem großen Formular herausgelesen.

Was ist dann die beste MVC-Interpretation in diesem Fall? Für alle View-Referenzen public-Getter schreiben? Ist dann irgendwie auch unschön. Oder die Controllerklasse als Parallelclass einsetzen? Also in der gleichen Datei?

 

[JavaProfi]

Nach meinem Verständnis erstellt aber der Controller die Views und das Model. Er ist der einzige der direkte Referenzen dazu hat und nicht die View.

Das stimmt so nicht. Der Controller erstellt i.d.R nicht das Model. Das Model existiert unabhängig von irgendeinem Controller und irgendeiner View. Eine Applikation besteht meistens aus mehr als nur einem Fenster. Also aus einer Vielzahl von Views. Jeder View hat in der Regel auch seinen eigenen Controller, aber nicht sein eigenes Model.

Soweit die Theorie, aber wie GUI-Programmer schon gesagt hat, gibt es Abwandlungen des MVC wie MVA (Model View Adapter) oder MVP. Das klassische MVC besitzt nur ein Model, mehrere Views und mehrere Controller, wobei i.d.R. zwischen einem Controller und einem View eine 1:1 Beziehung existiert.

Daher existiert in vielen Applikationen für jede View eine eigenes Package in dem sich auch der zugehörige Controller befindet. (Eine View kann allerdings wieder aus mehreren Teilsichten bestehen, die wiederum eigene Controller haben können.)

Da der Controller ja auch die Komponenten des View auslesen muss, sind diese dann protected deklariert. Damit kann nur der Controller des View auf die Komponenten zugreifen.

Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“. Das Modell ist das zu beobachtende Subjekt, auch Publisher, also „Veröffentlicher“, genannt. Das Model implementiert also das Interface "Observable". Die View beobachtet das Model, implementiert somit das "Observer"-Interface.

Je nach Implementierung des MVC (und das sind alles konforme Implementierungen) kann auch der Controller das Modell beobachten, um auf Änderungen des Models reagieren zu können.

Gruß
JP

 

[GUI-Programmer]

Wollt eigentlich nur sagen, dass es oft vorkommt, dass der/ein Controller speziell der View angepasst wird, bzw. zu einer best. View gehört. Sonst hat JavaProfi schon alles gesagt.

 

[Rudolf]

Oh, ok danke dann für diese Informationen.

Jetzt die Frage. JavaProfi hat gesagt, dass die Felder der View oft protected deklariert sind, damit sie der Controller auslesen kann. Das macht so für mich keinen Sinn, weil nur Klassen, die eine andere Klasse mit protected Feldern erweitern, darauf zugreifen können. Erweitert der Controller die View Klassen oder wie ist das gemeint?

 

[GUI-Programmer]

Erweitert der Controller die View Klassen oder wie ist das gemeint?

Nein, ist nicht so gemeint. Protected deshalb, damit man eben nicht für jede GUI-Komponente ala JPanel Instanz, JLabel Instanz... extra Getter schreiben muss (Setter werden in der Regel nicht benötigt). Und die Grundregel lautet ja: So wenig Sichtbarkeit wie nur möglich. Folglich würde sich Package-Private auch anbieten.

Dennoch kreiere ich persönlich dann doch lieber Getter, bzw. lasse sie mir von Eclipse kreieren.

 

[JavaProfi]

Jetzt die Frage. JavaProfi hat gesagt, dass die Felder der View oft protected deklariert sind, damit sie der Controller auslesen kann. Das macht so für mich keinen Sinn, weil nur Klassen, die eine andere Klasse mit protected Feldern erweitern, darauf zugreifen können.

Das ist nur die halbe Wahrheit.
Das was ich gepostet habe macht schon Sinn. Sonst würden einige meiner MVC-designed Applications nicht laufen.

Zum Nachlesen: Have a look here --> Java ist auch eine Insel – 6.7 Vererbung und dort unter 6.7.5
oder auch hier: Controlling Access to Members of a Class (The Java™ Tutorials > Learning the Java Language > Classes and Objects)

Wenn du magst, kannst du natürlich auch über getter-Methoden auf deine dann private deklarierten Komponenten zugreifen.


@GUI-Programmer

...Und die Grundregel lautet ja: So wenig Sichtbarkeit wie nur möglich. Folglich würde sich Package-Private auch anbieten.

Geht natürlich auch, dann kann aber eine SUB-Class nicht mehr auf die Member-Variable zugreifen.

Gruß
JP

 

[Rudolf]

Nein, ist nicht so gemeint. Protected deshalb, damit man eben nicht für jede GUI-Komponente ala JPanel Instanz, JLabel Instanz... extra Getter schreiben muss (Setter werden in der Regel nicht benötigt). Und die Grundregel lautet ja: So wenig Sichtbarkeit wie nur möglich. Folglich würde sich Package-Private auch anbieten.

Dennoch kreiere ich persönlich dann doch lieber Getter, bzw. lasse sie mir von Eclipse kreieren.

Eine andere Programmierregel lautet, dass man sich niemals auf die Ordnerstruktur bezüglich visibility der Felder verlassen soll.

Ein Beispiel.

Ich nehme package private und haue für jede View ein eigenes Package raus, in dem die View und der dazugehörige Controller befinden. Die Felder der View mache ich als package private. Dann kommen mehrer Viewordner nach dem gleichen Schema dazu.

Später kommt ein **** und denkt sich, dass es cooler wäre, wenn alle Viewklassen in einen Ordner kommen und alle Controllerklasse in einen anderen Ordner. Dann habe ich ein Problem mit der Visibility.

Was sollte man tun?

Kann jemand offizielle Codingregeln zitieren, die das Problem aufgreifen und eine Empfehlung geben?

 

[JavaProfi]

Es wurde hier alles gesagt.
Den Rest des Weges musst du alleine gehen.