Projektstruktur

[xerion21]

Hi, ich hoffe ich bin hier im richtigen Unterforum:

Hallo zusammen,

mich würd emal interssieren, wie ihr so eure Projekte aufbaut. Da ich momentan mit meinem Projektaufbau immer unzufriedener werde
Momentan verfolge ich eine Art MVC-Model.

Das sieht momentan so aus (in Java):
View:
lädt ein Frame aus den selbst erstellten Utils und benutzt die von dem Frame verwendeten Setter/Getter
Model:
ein einfaches Model, in dem die Daten zwischengespeichert werden können
Controller:
Verbindet den View und den Controller (Lädt die Daten aus dem Model heraus und setzt diese im View ein und anders herum).
Hat 2 Unterklassen, welche für die ActionListener zuständig sind.

Nun habe ich ne Frage, wer kümmert sich darum, die Daten aus dem Modell in eine Datenbank bzw. XML zu speichern? Denn nachdem die Daten in den View eingetragen worden sind udn auf speichern geklickt worden ist, sollen die Daten in einer Datenbank aus dem Modell gespeichert werden.

Nun habe ich auch, da das Projekt immer größer wird, mehrere Controller und mehrere dazu passende Views. Wie verbinde ich die verschiedene Controller miteinander? Ich würde gerne ein MainFrame haben, über die man dann andere SubFrames aufrufen kann.

Wie stelle ich sowas an?

Ich hoffe ich habe mich einigermaßen verständlich ausgedrückt

 

[Joose]

3 Schichtenanwendung, 3-Tier Architektur sind vielleicht Begriffe welche du suchst.

MVC ist für viele Programmierer nur ein Struktur der UI-Schicht innerhalb der eigentlichen Anwendung.

 

[xerion21]

3 Schichtenanwendung, 3-Tier Architektur sind vielleicht Begriffe welche du suchst.

MVC ist für viele Programmierer nur ein Struktur der UI-Schicht innerhalb der eigentlichen Anwendung.

3 Tier-Programmierung sagt mir was. Habe ich auch schonmal verwendet. Jediglich finde ich dann keinen Zusammenhang zu dem MVC-Model, bzw finde ich da kein Zusammenhang
WIe kann dann die Projektstruktur aussehen?

 

[Joose]

3 Tier-Programmierung sagt mir was. Habe ich auch schonmal verwendet. Jediglich finde ich dann keinen Zusammenhang zu dem MVC-Model, bzw finde ich da kein Zusammenhang
WIe kann dann die Projektstruktur aussehen?

Eine 3 Schichtenanwendung besteht in der Theorie aus:

• UI
• Businesslogic
• Dataaccess

Jede Schicht sollte entsprechend auf Interfaces basieren, so ist ein einfacher Austausch einer Schicht ohne große Codeänderungen möglich (Datenspeicherung von XML auf Sql umstellen, oder von DB2 auf Oracle usw.)

MVC würde in diesem Fall der UI-Schicht entsprechen:
M(odel): Du bekommst von der Businesslogic Objekte welche alle Daten zum Anzeigen enthalten
V(iew): Die eigentlichen Oberfläche deiner Anwendung
C(ontroller): Sorgt eben dafür das die Daten von der Oberfläche ins Model kommen und umgekehrt, implementiert die ActionListener

Eine 3-Schichten Anwendung wird vor allem für verteilte Systeme verwendet.
Hier laufen Businesslogic- und Datenzugriffsschicht als Serveranwendung zentral und jeder Client verbindet sich mit diesem Server.
Und dieser Client kann im Sinne von MVC aufgebaut sein.

Für Anfänger ist das Ganze aber vielleicht überdimensioniert, daher gehen viele Tutorials nur soweit auf MVC als vollständige Applikation ein.
Der Datenzugriff sollte hier meiner Meinung nach im Controller durchgeführt werden.
Das Model ist zum Halten der Daten zuständig nicht um diese zu laden. -> Woher soll ein Auto wissen wie es geladen/erstellt/gespeichert wird?

 

[xerion21]

Eine 3 Schichtenanwendung besteht in der Theorie aus:

• UI
• Businesslogic
• Dataaccess

Jede Schicht sollte entsprechend auf Interfaces basieren, so ist ein einfacher Austausch einer Schicht ohne große Codeänderungen möglich (Datenspeicherung von XML auf Sql umstellen, oder von DB2 auf Oracle usw.)

MVC würde in diesem Fall der UI-Schicht entsprechen:
M(odel): Du bekommst von der Businesslogic Objekte welche alle Daten zum Anzeigen enthalten
V(iew): Die eigentlichen Oberfläche deiner Anwendung
C(ontroller): Sorgt eben dafür das die Daten von der Oberfläche ins Model kommen und umgekehrt, implementiert die ActionListener

[...]

Für Anfänger ist das Ganze aber vielleicht überdimensioniert, daher gehen viele Tutorials nur soweit auf MVC als vollständige Applikation ein.
Der Datenzugriff sollte hier meiner Meinung nach im Controller durchgeführt werden.
Das Model ist zum Halten der Daten zuständig nicht um diese zu laden. -> Woher soll ein Auto wissen wie es geladen/erstellt/gespeichert wird?

Also so wie ich dann die Sache sehe, tielt sich die Sache nun wie folgt auf:
in der UI steht der Controller und der View.
Das Modell bekommt die UI vom BuisnessLayer mit übertragen.
Das Modell selbst liegt im BL und wird auch von diesem mittels Verbindung über den DAL mit Daten gefüllt.
Oder liege ich da Falsch?

Der Controller ist dann doch sozusagen die BL?

Der Programmablauf sieht dann wie folgt aus:
main ruft den allgemeinen BL auf, dieser ruft über einen privaten Controller dann die Swing-Komponente auf und beliefert diese irgendwie mit Daten.

Hast du dafür ein Beispiel?

 

[Joose]

in der UI steht der Controller und der View.

Wobei der Controller meist nichts anderes ist als ein Listener der auf Events wartet.
Kann man natürlich beliebig erweitern

Das Modell bekommt die UI vom BuisnessLayer mit übertragen.
Das Modell selbst liegt im BL und wird auch von diesem mittels Verbindung über den DAL mit Daten gefüllt.
Oder liege ich da Falsch?

Die Modelklassen selbst sollten in einem eigenen Jar liegen, da du vom BAL (Businessapplicationlayer) und DAL Zugriff auf diese Klassen brauchst.
(Und je nachdem wie du der UI die Daten übermittelst diese auch)

Der BAL kann den DAL ansprechen und nach Daten verlangen und bekommt diese schon als fertige Objekte zurück.

Generell sollte man beachten:
Bei einer 3T Architektur kann eine Schicht nur auf die Schichten unter ihr zugreifen und selbst das sollte über Interfaces passieren.

UI => BAL => DAL

Der Controller ist dann doch sozusagen die BL?

Genau, vieles was du beim MVC im Controller machst verschiebt sich nun in den BAL.

Hast du dafür ein Beispiel?

Habe leider keines bei der Hand, aber es man findet sicher das eine oder andere Beispiel im Internet bzw. sucht einfach nach ein paar OpenSource Projekten

 

[xerion21]

Wobei der Controller meist nichts anderes ist als ein Listener der auf Events wartet.
Kann man natürlich beliebig erweitern



Die Modelklassen selbst sollten in einem eigenen Jar liegen, da du vom BAL (Businessapplicationlayer) und DAL Zugriff auf diese Klassen brauchst.
(Und je nachdem wie du der UI die Daten übermittelst diese auch)

Ich habe sie bis Dato einfach in einem anderem Paket liegen. Warum sollte ich Sie denn in ein eigenes Jar legen?
Bis jetzt habe ich am Ende nur eine Jar-Datei für das ganze Projekt.

 

[Thallius]

Und wenn Du Deine Controller miteinander verknüpfen willst, dann ist das auch der falsche Weg. Du kannst Sie gerne miteinander Kommunizieren lassen aber der große Vorteil von MvC ist ja die wiederwendbarkeit der einzelnen Komponenten und wenn ein Controller nicht ohne einen anderen "Leben" kann, da ist was faul am Konzept.

Gruß

Claus

 

[Joose]

Warum sollte ich Sie denn in ein eigenes Jar legen?
Bis jetzt habe ich am Ende nur eine Jar-Datei für das ganze Projekt.

Generell bei verteilten Anwendungen liegt BAL und DAL meist am Server und der User hat nur einen Client (nur die UI Schicht).

Auch bei nicht verteilten Anwendungen macht es Sinn für jede Schicht eine Jar zu erstellen.
1. kommt man nicht in Versuchung vom DAL direkt auf die UI zuzugreifen usw.
2. kannst du einfach die Jar der DAL austauschen ohne den Rest anzugreifen -> wenn du zum Beispiel von XML Speicherung auf eine Datenbank umsteigst

Und damit DAL und BAL jeweils mit den gleichen Model(klassen) arbeiten sollten diese wiederum in einer eigenen Jar liegen (wird auch Domainmodel(?) genannt).