Verständnis bzgl. MVC

[psalm69]

Hallo,
ich werde meine Abschlußarbeit vermutlich in Java schreiben.
Da ich mich Java noch nie kontakt hatte, bin ich mich derzeit einwenig am vorbereiten. Dazu wollte ich in kleines Kundenverwaltungssystem schreiben.

Nun habe ich schnell gemerkt, daß es nötig ist die Daten zu strukturieren und bin auf das MVC-Modell gestoßen.
Ich habe versucht meinen bisherigen Code umzuschreiben, bin mir aber ziemilch sicher, daß ich das Modell nicht ganz verstanden habe.

Es wäre schön, wenn sich jemand mit etwas mehr Erfahrung den Code ansehen- und mir dazu Feedback geben würde. :### Bin für jeden Tipp dankbar!


Leider ist es schon relativ viel Code und extrem unübersichtlich, hierfür will ich mich entschuldigen.

Viele Grüße,
Jens

Als Archiv

Oder einzeln
Start
KundenController
KundenView (sorry für den Code!) :?
KundenModel
User-Klasse

 

[ARadauer]

nur kurz rein geschaut...
den Datenzugriff im Model würd ich in ein DAO auslagern

ArrayList userlist = new ArrayList(); steht bei dir in der view, das gehört meiner meinung nach ins model...

 

[Guest]

Hi ARadauer,
danke für den Tipp! Hab die ArrayList an ihren vorgesehenen Platz gesteckt und in Sachen DAO werd ich mich morgen mal belesen. Was meisnt? Ist das Modell korrekt umgesetzt? Im Controller sind wirklich nur die Mouse-Listener, die dann Funktionen in der View- oder im Modell aufrufen?

Grüße,
Jens

 

[maki]

imho gehört der Zugriff auf die Persistenz in den Controller, die UserKlasse wäre dein Model.

 

[blaah]

Hallo Maki,
ach so - ist natürlich auch ein Ansatz.
Und wo pack' ich dann das DB-Handling hin? In eine eigene Klasse?

Grüße,
Jens

 

[maki]

>> ach so - ist natürlich auch ein Ansatz.

Ja, der MVC Ansatz

>> Und wo pack' ich dann das DB-Handling hin? In eine eigene Klasse?

Auf jeden Fall!
Am besten pro Entität/Model ein DAO.

 

[blaah]

Hallo maki,
das hast schön gesagt :wink: :roll:
Vielen Dank schoneimal für den Tipp!

Hab das Ganze nun geändert. Scheint mir auch logischer. Nun kann ich vom KundenController aus auch besser auf der KundenView arbeiten. Eine neue Datei ist folglich hinzugekommen, die anderen oben habe ich auf dem Server "ge-updated".

Neu: DBhandling.java

Kommt dies dem Ansatz nun näher?

Bin mir immer noch nicht sicher, ob z.B. die "printTable" in den Controller oder in die View gehört.
Besser gefallen würd sie mir auf jedenfall im Controller, wo sie jetzt auch ist - dann wäre in der View wirklich nur der Code, der das Aussehen beschreibt.

Schöner und übersichtlicher wäre es auch, wenn man die Event-Handler außerhalb des Konstruktors der KundenControll definieren könnte. Dies ist mir allerdings nur beim Button gelungen.

Grüße,
Jens

 

[maki]

Da DBHandling ist schon ok unter disen Umständen.

Wohin ein TableModel und der Eventhandler gehören solltest du dir besser von jemandem mit Swing Erfahrung erklären lassen

In JSF hätte ich so etwas in die ManagedBean verpflanzt, ist der sog. PageController.

 

[ARadauer]

imho gehört der Zugriff auf die Persistenz in den Controller, die UserKlasse wäre dein Model.

darüber lässt sich streiten... hab schon beides gesehen...

ob jetzt der controller über das dao, die daten lädt und sie dem model setzt oder der controller das model anweist sich die daten selber über eine eigenes dao zu laden ist meiner meinung nach egal... ich habe meistens noch eine service schicht zwischen model und dao die ich bequem über spring rmi auf einen server auslagern kann...

meine controller konrtollieren eigentlich den gui ablauf, weniger den fachlichen ablauf...

 

[byte]

Das TableModel bindet die View (Table) mit deinen Fachobjekten und gehört daher in den Controller. EventHandler gehören ebenfalls in den Controller, da sie Logik beinhalten und meistens Logik in den Fachobjekten triggern.

 

[byte]

meine controller konrtollieren eigentlich den gui ablauf, weniger den fachlichen ablauf...

Seh ich genauso. Wobei natürlich der Controller auch durchaus Logik in den Fachobjekten triggern können, wenn man den domain driven Ansatz vertritt.

 

[ARadauer]

Das TableModel bindet die View (Table) mit deinen Fachobjekten und gehört daher in den Controller.

mein model implementiert meist ein AbstractTableModel, der controller hat dann natürlich eine referenz darauf...