MVC Design

HazelNut

Mitglied
Hey ich hätte noch eine Frage zum MVC.

Ich habe einen Conroller ein Datenmodel und ein MainFrame.

Solle das Model direkt Datenbankquery erledigen oder sollte es die Anfragen an eine eigene Klasse weiterleiten?

Das MainFrame verwendet noch eine ContentPane welche eben den Content darstellt. Sprich eine eigene Klasse ist.
Die Daten die dort angezeigt werden, kommen durch eine JList zustande.
Wie genau sollte da meine Interaktion aussehen?

Sollte wenn ich in meiner Liste auf einen Eintrag geklickt habe dies dem mainFrame mitgeteilt werden oder direkt an das Model gehen, welches dann direkt das ContentPane informiert.
Oder ist es eher zu empfehlen alles über das MeinFrame zu machen, weil im Endeffekt ändert sich im Mainframe eh nie was.
Oder sollte ich wenn auf einen Eintrag in der Liste geklickt wird dies entweder über das Mainframe oder direkt and den Controller weiterleiten, welcher dann das Model versändigt?
Oder am einfachsten Controller Actionlistener implementieren lassen und dann alle angeklicketen Einträge zum Model durchschleifen?

Es ist kein großes Projekt, aber es wäre interessant zu wissen, was am efizientesten ist.
 
Solle das Model direkt Datenbankquery erledigen oder sollte es die Anfragen an eine eigene Klasse weiterleiten?

Ich behaupte, ein Model sollte unabhängig von der zugrunde legenden DB sein. Denn es sollte einfach möglich sein, das Model weiter zu verwenden, auch wenn sich die DB ändert. Dieses geht meiner Meinung nach am besten, wenn das Model an eine andere Klasse delegiert.

Meistens sind hier abstrakte Klassen im Einsatz, die dann spezifisch für eine bestimmte DB (mySQL, Oracle, Postgres, ...) erweitert wird.
 
Okay, so hatte ich mir das auch gedacht.

Sollte der Controller das Model und die DBClass einzeln ansprechen oder das Model auch die DbClass verwenden, Was wir persönlich sinniger scheint.
 
Okay, habs auch so gemacht.

Noch eine Frage.

Also ich habe eine Klasse CommonType eine Literal die von CT erbt sowie Collection die ebenfalls von CT erbt.
Ja, Literale stehen halt für sich und sind die "Information" und Collection sind Ansammlungen, welche selbst Collections enthalten können sowie Literale.
Passt das so? Im Endeffekt habe ich beide nur von der Superclass erben lassen, damit ich das dann in einer List/Map eintragen kann, oder sollte ich das in die Richtung von Interfaces machen?
Die SuperClass besteht im Endeffekt nur aus der Methode getName und dem Konstruktor....

Mein Model hätte eben eine ArrayList/Map in welcher das Zeugs gespeichert wird. Wobei entweder Literale oder Collections gespeichert werden.
Dabei hatte ich gedacht, dass Collections die Referenz auf die Literale, oder weitere Collections besitzen.

Der Hintergrund ist der, das die Daten dann in einer TreeList angezeigt werden, Collections logischerweise als Ordner und Literale als Blätter.
 
Also ich habe eine Klasse CommonType eine Literal die von CT erbt sowie Collection die ebenfalls von CT erbt.
Das bezieht sich jetzt hoffentlich nicht mehr auf's MVC-Pattern, dass hat nämlich nichts mit Vererbung und Klassenhirarchien zu tun...
Ja, Literale stehen halt für sich und sind die "Information" und Collection sind Ansammlungen, welche selbst Collections enthalten können sowie Literale.
Passt das so? Im Endeffekt habe ich beide nur von der Superclass erben lassen, damit ich das dann in einer List/Map eintragen kann,
oder sollte ich das in die Richtung von Interfaces machen?[/QUOTE]Wenn
Code:
CommontType
keine Logik aufnimmt, die in beiden Spezialisierungen benötigt wird ist ein Interface besser, schon deshalb, weil
Code:
Collection
und
Code:
Literal
dann unabhängige Vererbungshirarchien habe können.

Die SuperClass besteht im Endeffekt nur aus der Methode getName und dem Konstruktor....
Ist aber eine gute gemeinsame Basis.

Mein Model hätte eben eine ArrayList/Map in welcher das Zeugs gespeichert wird. Wobei entweder Literale oder Collections gespeichert werden.
Schriebst Du nicht gemeinsame Liste?
Dabei hatte ich gedacht, dass Collections die Referenz auf die Literale, oder weitere Collections besitzen.

Der Hintergrund ist der, das die Daten dann in einer TreeList angezeigt werden, Collections logischerweise als Ordner und Literale als Blätter.
Die Frage ist wahrscheinlich Blöd, aber warum nimmst Du nicht [JAPI]JTree[/JAPI]? How to Use Trees (The Java™ Tutorials > Creating a GUI With JFC/Swing > Using Swing Components)

bye
TT
 
Das bezieht sich jetzt hoffentlich nicht mehr auf's MVC-Pattern
Nöö, natürlich nicht die werden halt zum Speichern der Daten verwendet.

Wenn CommontType keine Logik aufnimmt
Die Drei Klassen haben gar keine Logik.

Ist aber eine gute gemeinsame Basis.
okay, dachte nur, dass eine eigene Klasse nur mit einem Feld nicht die beste Lösung ist, zudem das eine ja eine Sammlung ist und das andere Literale, mM nach haben die ja nicht gerade die größten gemeinsamkeiten, außer dem Namen 😀

Schriebst Du nicht gemeinsame Liste?
Versteh ich jetzt nicht so ganz, aber ja die erstellten Collections und Literale werden alle in eine Liste geschrieben, wobei ich inzwischen mit HashMap liebäugle aber das ist ja unwichtig.

Die Frage ist wahrscheinlich Blöd, aber warum nimmst Du nicht JTree
Hab mich verschrieben, verwende JTree 🙂
 
Das Tutorial habe ich mir wohl angeschaut.
Hmm, okay, ich dachte ich würde das Interface treeNode benötigen.
Kann ich dann wenn ich es direkt mache, die Infos ausfiltern?
Sprich, dass nur noch Blätter und Knoten mit "d" angezeigt werden?
 
Das Tutorial habe ich mir wohl angeschaut.
Hmm, okay, ich dachte ich würde das Interface treeNode benötigen.
Das brauchst Du auch, aber [JAPI]DefautMutableTreeNode[/JAPI] implementiert das ja schon.

Kann ich dann wenn ich es direkt mache, die Infos ausfiltern?
Sprich, dass nur noch Blätter und Knoten mit "d" angezeigt werden?
Du mußt halt alle "children" Methoden so überschreiben, dass sie ihre Kinder auf das Filterkriterum prüfen...

bye
TT
 

Zurück
Oben