MVC Fehlerbehandlung

davidh38

Bekanntes Mitglied
Hallo Javagurus,

sollte die Umwandlung von beispielsweise Strings in Integer sowie Fehlerabfangmechanismen in der View oder im Model erfolgen?
 
M

maki

Gast
Ganz klares "kommt darauf an", der Controller wäre auch eine Option.
Ins Model würde ich persönlich es nicht machen.
 
M

maki

Gast
Auf das "MVC" dass du meinst.
Es gibt wohl leider kaum einen anderen Begriff in der SW Entwicklung der mehr Bedeutungen hat und noch mehr Fehlinterpretationen.

Würde dass den Controller machen lassen, so hält man Logik/Fachlichkeit aus der View raus.
 

davidh38

Bekanntes Mitglied
Was denkst du, wäre der beste Weg, damit ich den Begriff MVC richtig verstehe. Ich habe mir jetzt ein Beispiel angeschaut und dies nachprogrammiert. Was sollte ich deiner Meinung nach noch tun?
 
M

maki

Gast
Was denkst du, wäre der beste Weg, damit ich den Begriff MVC richtig verstehe. Ich habe mir jetzt ein Beispiel angeschaut und dies nachprogrammiert. Was sollte ich deiner Meinung nach noch tun?
Es würde dir mehr bringen, zu erklären, was du mit "MVC" meinst, dann könnten ggf. auch andere User etwas dazu sagen.

Echtes MVC wie in Smalltalk in den 80er Jahren?
Oder meinst du Java mit Swing?
Oder meinst du eine WebApp aus Servlets und JSPs? (ist zB. kein "echtes" MVC)
Oder oder oder....

Wenn der Controller bei dir die Updates zwischen View und Model macht, sollte der Controller konvertieren.
 

Spin

Top Contributor
Hallo,

ich denke nicht dass dir hier jemand eine Antwort geben kann, welche Klasse in welches Package gepackt werden sollte.

Schau dir Frameworks an die mit MVC realisiert wurden.
Weiter würde ich niemals Logik die dem View angehört ins Model packen.

Dein Beispiel ist keineswegs eine MVC Frage sondern gehört je nach Anwendung in VIEW, CONTROLLER oder MODEL.

Die TypUmwandlung würde ich daher bei der Eingabe eines Strings in einem Textfeld im View machen. Wenn ich jedoch einn String aus einer Datei lade würde ich das in einem Model machen.

grüße Spin
 

Michael...

Top Contributor
Um maki zu zitieren "kommt darauf" an ;-)

Ist es für den Anwender relevant bzw. soll es für ihn direkt ersichtlich sein, ob seine Eingabe ungültig ist würde ich eventuelle Fehler/Falscheingaben direkt in der View abarbeiten. Ist es egal bzw. können fehlerhafte Daten eventuell "repariert" werden würde ich das ins Model packen.

Und dann kommt es natürlich auf den konkreten Anwendungsfall an ;-)
 

davidh38

Bekanntes Mitglied
Ganz klar: Kommt darauf an.

Ist das hier ein Quiz, in dem wir erraten müssen, was du gerade denkst? ;)

Nein, ich bin dankbar für eure Hilfe! Ich war nur vewirrt wegen der Formulierung "Frameworks, die mit MVC realisiert wurden" und ich habe denke er meint stattdessen "Frameworks, die MVC realisieren" oder habe ich etwas falsch verstanden?
 
M

maki

Gast
Was du nicht verstanden hast: Erkläre dich, was meinst du konkret wenn du "MVC" sagst?

SWT/JFace, Swing, Servlets/JSP, JSF, Smalltalk, GWT, Velocity, struts, SpringMVC, Spring RichClient, Blindenschrift, etc. pp.
 

ThreadPool

Bekanntes Mitglied
PS: Es gibt in Java auch das MVP.

Das ist jetzt zwar ziemlich Off-Topic aber bei dem Wort MVP triffst du auf einen ähnlichen "Wildwuchs". Ich hab mal ein paar Threads rausgekramt wo ausführlich über das MVC und Co. referiert wurde und auf meine Meinung zu dem Thema verlinkt.

http://www.java-forum.org/allgemein...l-view-controller-architektur.html#post705105
http://www.java-forum.org/awt-swing-swt/109203-designfrage-mvc.html#post700941
http://www.java-forum.org/allgemeines/91829-mvc.html#post596074

Die Links helfen dem dem OP aber nun nicht wirklich bei der Lösung seines Problems. Da kann man nämlich, wie die anderen nur sagen, kommt darauf an.

Beim Beispiel des OP gibt es nicht viele Möglichkeiten. Daten können eine Anwendung nur über definierte Eingänge betreten. Sind intern erzeugte Daten (ohne Userinteraktion) defekt ist man selbst schuld aber dafür gibts Unit-Tests und die ganze Vor-/Nachbedingungsgeschichte.

Betrachtet man die Eingänge gibt es meist überschaubar viele Möglichkeiten, oft nur GUI-"Schicht" (Views, Application Model oder Controller) oder Domänenmodell. Eingaben über das GUI kann man auch an Ort und Stelle auf syntaktische Korrektheit überprüfen, z.B. Eingabevalidatoren an Textfeldern etc. Auf Seite des Domänenmodells ist die Frage wie geht man mit defekten Daten von aussen um, versucht man etwas zu retten oder nicht. An dem Stück SW an dem ich gerade hocke fliegen z.B. Exceptions bei korrupten Daten, es wird nicht versucht etwas zu retten, diese Exceptions wandern solange nach oben bis sie in einem Allgemeinen Exceptionhandler landen der eine entsprechende Nachricht (den hoffentlich aussagekräftigen Inhalt der Exception) auf dem Bildschirm ausgibt.
 
Zuletzt bearbeitet:
M

maki

Gast
ThreadPool, MVP ist IMHO um Welten eindeutiger als MVC, vor allem die Beziehung zwischen Model, Presenter und View ist da eindeutig. Erweiterungen sind Passive View (Humble Object).
 

ThreadPool

Bekanntes Mitglied
ThreadPool, MVP ist IMHO um Welten eindeutiger als MVC, vor allem die Beziehung zwischen Model, Presenter und View ist da eindeutig. Erweiterungen sind Passive View (Humble Object).

Ja die Verhältnisse sind schon geordneter als beim MVC, wahrscheinlich auch, weil es "moderner" ist. Aber es gibt eben auch mehrere Varianten, hatte ich hier (http://www.java-forum.org/allgemein...l-view-controller-architektur.html#post705105) erwähnt. Ich halte es für wichtig wenn man über solche Prinzipien spricht zu erwähnen welche Variante man meint.
 
M

maki

Gast
Ja die Verhältnisse sind schon geordneter als beim MVC, wahrscheinlich auch, weil es "moderner" ist. Aber es gibt eben auch mehrere Varianten, hatte ich hier (http://www.java-forum.org/allgemein...l-view-controller-architektur.html#post705105) erwähnt. Ich halte es für wichtig wenn man über solche Prinzipien spricht zu erwähnen welche Variante man meint.
Sehe ich genauso, aber vor allem fehlen mir immer noch die Infos des TS was er da eigentlich hat, sonst könnte man sinnvoller Antworten, zB. wäre der JSR 303 eine Möglichkeit der Validierung, die aber dann im Model stehen sollte.
 

Ähnliche Java Themen


Oben