MVC und Datenprüfung

[Elephant]

Hallo,

ich komm wieder mal beim MVC nicht ganz weiter. Ich würde gerne wissen (auch mal ganz unabhängig vom MVC) wo eine Datenprüfung durchgeführt wird.

Also z.B. wenn ein Objekt als Variable einen Pfad enthält, wo soll dieser geprüft werden (z.B. ob die Datei überhaupt existiert oder falls ein bestimmter Dateityp verlangt wird).

Ich habe bis jetzt immer gedacht, das soll in die Methode 'eingebaut' werden, über die man die Variable setzt. Also hier z.B. setPath(...). Aber jetzt habe ich gelesen, dass das die Aufgabe des Controllers wäre. Und das dieser dann nur 'validierte' Daten im Model setzt also per setPath(...) übergibt.

Weiß jemand wie man das machen sollte. Prüft man Daten in den setter Methoden oder übergibt man erst gar nicht 'falsche' Daten?

 

[Beni]

Grundsätzlich ist jedes Objekt "verpflichtet" sich selbst valid zu halten. D.h, das Model sollte falsche Eingaben umgehend mit einer Exception beantworten... Damit kannst du dir *viel* Zeit beim Fehlersuchen ersparen.

Da herumfliegende Exceptions im Programm nicht schön sind, sollte der Controller dann dafür sorgen, dass das Model nichts falsches bekommt.

Besonders toll ist es natürlich, wenn bereits die View so gebaut ist, dass der Benutzer gar keine Möglichkeit für eine Falscheingabe hat (dann kannst du die Prüfung im Controller auch weglassen).

 

[Elephant]

Danke erstmal für Deine Antwort, ich hab nur nicht alles so richtig verstanden.

Also Du hast geschrieben:

Da herumfliegende Exceptions im Programm nicht schön sind, sollte der Controller dann dafür sorgen, dass das Model nichts falsches bekommt.

Also man hat z.B. eine setter Methode und man übergibt eine Zahl. Die Zahl darf nur in einem bestimmten Intervall sein. Also prüfe ich in der setter Methode ob die Zahl im Interval liegt. Was mache ich nun, wenn sie nicht im Intervall liegt? Eigentlich denke ich werfe ich eine Exception, die dann das Objekt abfangen muss, die die setter-Methode 'benutzt'.

Jetzt schreibst Du aber, dass der Controller möglichst dafür sorgen soll, dass das Model gar nichts falsches bekommt. Das heißt aber ja, dass ich da auch schon prüfen sollte ob die Zahl in dem Intervall liegt. Dann müsste ich alle Datenprüfungen immer wenigstens doppelt implementieren. Ist das sinnvoll? Oder sollte ich die Exception dann im Controller abfangen?

 

[Beni]

Ja, es läuft auf eine doppelte Überprüfung hinaus. Guck dir die Standardlib an, die ist voller solcher doppelten Tests (schonmal einer Liste einen negativen Index übergeben? 1. Machst du das nicht, 2. würde die Liste eine Exception werfen).

Die meisten Tests sind aber trivial (in der Art von "Integer muss grösser als 0 sein"), da macht ein doppelter Test nichts aus.
Bei den anderen muss man meist ein Objekt übergeben, und das ist ja eigentlich per Definition schon korrekt (wegen der Verpflichtung, immer valid zu bleiben).

Das Problem an Exceptions ist, dass sie eine Ausnahmesituation beschreiben. Wenn in einem Progi eine Ausnahme auftritt, bedeutet das eigentlich, dass es einen Programmierfehler hat. Deshalb sollte man sich Exceptions für die "dicken Dinger" aufsparren.

 

[Elephant]

O.k. danke.

Ich habe noch eine Zusatzfrage, vielleicht kannst Du die mir auch beantworten, wäre echt nett
Wenn ich eine Eingabe-Maske habe mit verschiedenen JTextfields, JComboBoxes usw. Leite ich dann alle Änderungen direkt an das Model weiter oder lese ich die ganzen Daten erst beim z.B. Klicken auf den Submit-Button aus und leite sie dann erst an das Model weiter.

Also ich meine, wenn ich jetzt z.B. etwas in ein JTextField eingebe, habe ich dann immer einen ActionListener (also einen Controller) dort angemeldet, der die Eingabe gleich im Model setzt?

 

[Beni]

Ich würde warten, bis auf den Submit-Button geklickt wurde. Dann kannst du auch sehr einfach einen "Cancel"-Button implementieren.

Auch eine Überprüfung, ob alles richtig eingegeben wurde, kannst du dann einfach "am Schluss" machen (und allenfalls ein Dialog "hier ist alles falsch!" aufpoppen lassen).

Während der Eingabe ist es ja auch oft so, dass mal was falsch ist. Der Benutzer kann nicht immer alles gleichzeitig editieren, und muss manchmal einfach etwas "illegales" eingeben.

 

[Elephant]

Danke, daran hat ich z.B. gar nicht gedacht, dass man ja auch Abbrechen kann.

 

[Guest]

Entschuldigung, wenn ich nochmal nachfrage.

Ich hab mir alles nochmal langsam durchgelesen und meine Frage ist nun, ob man bei der Validierung von Daten in Objekten eine Exception werfen sollte, die von der RuntimeException abgeleitet ist, die man also nicht per throws etc. weiterleiten/fangen muss. So dass sich also i.A. der Programmierer drum kümmern muss, dass so eine Exception gar nicht auftritt. Oder ob man eine Exception wirft, die man abfangen muss.

Wenn man eine Exception wirft, die man abfangen muss, muss man ja bei jedem set... ein try... catch einbinden. Ist ja nicht so geschickt.

 

[Beni]

Die meisten Setter verwenden irgendeine RuntimeException, besonders die IllegalArgumentException ist sehr beliebt.

Wenn die Exception auf einen Programmierfehler hindeuten soll, nimm eine RuntimeException (90% aller Faelle)

Wenn die Exception ein kalkuliertes Risiko sein soll, nimm eine andere Exception (10% aller Faelle). Z.B. IOException: es kann nunmal passieren, dass eine Datei ploetzlich geloescht wird, der Programmierer kann da nix machen.

 

[Guest]

Danke für Deine Hilfe, hat mir echt geholfen.