Verzeichnisstruktur bei MVC

[UnkiDunki]

Hi,

ich habe eine kurze Frage, die man vielleicht nicht eindeutig beantworten kann, es aber grundsätzlich vielleicht doch schon gewisse Präferezen geben dürfte:

Die Verzeichnisstruktur meines Projektes würde am besten wie aussehen?
Gruppieren nach "Typen" (Models, Views und Controllers) z.B. gui.mvc.model.csvreader oder nach "Komponenten"? Für dieses Beispiel also z.B. gui.csvreader.model, gui.csvreader.view und gui.csvreader.controller.

Oder gibt es da noch eine andere "bessere" Variante?

Danke im Voraus

 

[Antoras]

Ich würde zu letzeren Variante greifen, da man so unterschiedliche Projekte besser außereinander halten kann. Wofür steht das gui am Anfang der package-Struktur? Da nimmt man normalerweise auch etwas was man wieder außeinander halten kann, z.B. TLDs.

de.csvreader.model
de.csvreader.controller

de.csvwriter.model
de.csvwriter.controller

Hier kann man sofort unterschiedliche Projekte/Projektteile erkennen, bei

de.model.csvreader
de.model.csvwriter

geht das nicht.

Durch die TLD am Anfang ist es z.B. möglich das Herkunftsland der Software zu erkennen, ein gui sagt da nur was wenn auch nur ein GUI in der Software enthalten ist. Das hat dann aber kein MVC.

 

[UnkiDunki]

... so unterschiedliche Projekte besser außereinander halten kann.

Das ist ein Argument

Wofür steht das gui am Anfang der package-Struktur?

Du meinst, weil man unter "gui" eigentlich die "views" zusammenfasst und "models" und "controllers" da nichts zu suchen haben? Mit den TLDs habe ich mich ehrlich gesagt noch nicht beschäftigt, ist aber ja in dem Zusammenhang sehr sinnvoll.

Danke für deine Antwort!

 

[maki]

... ein gui sagt da nur was wenn auch nur ein GUI in der Software enthalten ist. Das hat dann aber kein MVC.

Hä?
Wo sollte sich MVC sonst abspielen wenn nicht ausschliesslich in der GUI?

 

[Antoras]

Ich mein, dass in einem package, das gui heißt, auch nur Objekte enthalten sein sollten, die auch mit dem GUI zu tun haben. Wenn da nun auch noch der Controller und das Model drin sind, dann ist das kein reines GUI mehr, sondern ja schon das MVC. Und dann beschreibt der package-Name gui nicht mehr was er beinhaltet.

 

[maki]

Ich mein, dass in einem package, das gui heißt, auch nur Objekte enthalten sein sollten, die auch mit dem GUI zu tun haben. Wenn da nun auch noch der Controller und das Model drin sind, dann ist das kein reines GUI mehr, sondern ja schon das MVC. Und dann beschreibt der package-Name gui nicht mehr was er beinhaltet.

Ähm... zu was sollte der Controller und das Model aus MVC denn sonst gehören ausser zur GUI?
MVC existiert nur in der GUI, und gehört auch nur dahin
Daher ist UI/GUI schon richtig imho.

 

[Antoras]

Ist das nicht Definitionssache? Ich mein, welche Applikation besitzt denn kein UI? GUI ist für mich die Oberfläche - wenn diese aber noch keine Logik besitzt, die ausgeführt wird sobald mit der Oberfläche interagiert wird, ist das für mich kein MVC. Das ist nur das View.

 

[maki]

Ist das nicht Definitionssache? Ich mein, welche Applikation besitzt denn kein UI? GUI ist für mich die Oberfläche - wenn diese aber noch keine Logik besitzt, die ausgeführt wird sobald mit der Oberfläche interagiert wird, ist das für mich kein MVC. Das ist nur das View.

WebServices, reine Serveranwendungen etc. besitzen keine GUI
Per Definition existiert MVC nur in der GUI, sonst nirgends, ist ja nix weiter als ein Paradigma für die GUI, und sonst nix, schon gar nicht was für die ganze Anwendung

Geschäftslogik hat ja in der GUI nix zu suchen, dafür gibt es eine eigene Schicht.
Nebenbei, das M in MVC ist meist ein PresentationModel, nicht unbedingt dasselbe was in der Logik Schicht verwendet wird. Der Controller (C) ist auch ein Teil der GUI, so wie die View.

 

[Antoras]

WebServices, reine Serveranwendungen etc. besitzen keine GUI

Aber auch diese besitzen eine Schnittstelle damit man mit ihnen interagieren kann. Diese ist nur nicht graphisch.

Per Definition existiert MVC nur in der GUI, sonst nirgends, ist ja nix weiter als ein Paradigma für die GUI, und sonst nix, schon gar nicht was für die ganze Anwendung

Ich finde, dass nicht MVC wichtig ist, sondern der Gedanke der Modularität dahinter. Modulares Design sollte man überall anwenden, da man nie wissen kann ob die Software in 5 Jahren vllt. doch noch mal geändert werden muss. Ob man das dann als MVC bezeichnet ist mir dann wurscht. Hauptsache das Pattern erfüllt seinen Zweck - egal ob in einem GUI oder sonst wo.

Geschäftslogik hat ja in der GUI nix zu suchen, dafür gibt es eine eigene Schicht.

Schichtdesign - der nächste Punkt über den man sich streiten kann.

Nebenbei, das M in MVC ist meist ein PresentationModel, nicht unbedingt dasselbe was in der Logik Schicht verwendet wird. Der Controller (C) ist auch ein Teil der GUI, so wie die View.

Von mir aus, darf man das gerne als eine Schicht bezeichnen, die dann in ein großes Ganzes (den Rest der Anwendung) integriert wird. Die einzelnen Schichten müssen aber wieder gesteuert werden. Ob man diese Steuereinheit dann als Controller oder sonst irgendwie bezeichnet halte ich wieder für Definitionssache, ja sogar für irrelevant. Man muss nur wissen was damit gemeint ist.

 

[ARadauer]

3 Schicht Architektur: Darstellung - Logic - Datenhaltung
Wenn das jemand MVC nennt, finde ich es nicht so verkehrt...
Um die Schichten gehts eigentlich im Pattern nicht, aber vom Prinzip der Trennung geht es, meiner Meinung nach, in die selbe Richtung...

 

[maki]

Aber auch diese besitzen eine Schnittstelle damit man mit ihnen interagieren kann. Diese ist nur nicht graphisch.

"UI" = User Interface
Nicht jede Anwedung hat sowas, manche Systeme haben eben nur schnittstellen mit anderen Systemen.

Ich finde, dass nicht MVC wichtig ist, sondern der Gedanke der Modularität dahinter. Modulares Design sollte man überall anwenden, da man nie wissen kann ob die Software in 5 Jahren vllt. doch noch mal geändert werden muss. Ob man das dann als MVC bezeichnet ist mir dann wurscht. Hauptsache das Pattern erfüllt seinen Zweck - egal ob in einem GUI oder sonst wo.

Mag ja sein, aber deione Aussage was MVC ist was nicht hat damit ja nix zu tun.

Schichtdesign - der nächste Punkt über den man sich streiten kann.

Klar kannst du auch ein Zwiebelmodell nehmen, aber auch da ist die UI getrennt vom eigentlichen System.

Von mir aus, darf man das gerne als eine Schicht bezeichnen, die dann in ein großes Ganzes (den Rest der Anwendung) integriert wird. Die einzelnen Schichten müssen aber wieder gesteuert werden. Ob man diese Steuereinheit dann als Controller oder sonst irgendwie bezeichnet halte ich wieder für Definitionssache, ja sogar für irrelevant. Man muss nur wissen was damit gemeint ist.

Dafür gibt es doch begriffe, Pattern zB. haben den Hauptzweck der Kommunikation.
Wenn man jetzt bestehende Begriffe mit feststehender Definition nochmals umdefiniert ("Alles ansichtssache"), kann man gleich alles "Banane oder "Apfel" nennen, da kein gemeinsames Vokabular besteht.

3 Schicht Architektur: Darstellung - Logic - Datenhaltung
Wenn das jemand MVC nennt, finde ich es nicht so verkehrt...

Sorry, das ist falsch, schon per Definition.

Einer der meistverbreiteten Irrtümer über MVC, gleich nach der Fehleinschätzung dass es ein Pattern ist.

 

[Antoras]

Einer der meistverbreiteten Irrtümer über MVC, gleich nach der Fehleinschätzung dass es ein Pattern ist.

Ich habs gewusst: Ich werde MVC nie verstehen. Ich glaub, das guck ich mir nochmal in 5 Jahren an oder so. Vllt. versteh ich es dann.

 

[maki]

Lies dir mal den Artikel von Fowler durch: GUI Architectures

Nicht erschrecken, da geht es bei Adam & Eva los und dann über MVC, MVP, usw.

 

[Ebenius]

Einer der meistverbreiteten Irrtümer über MVC, gleich nach der Fehleinschätzung dass es ein Pattern ist.

Wenn schon genau… MVC ist ein Pattern. Es ist kein Design Pattern. Wohl aber ein Architectural Pattern.

Ebenius

 

[maki]

Wenn schon genau… MVC ist ein Pattern. Es ist kein Design Pattern. Wohl aber ein Architectural Pattern.

Ebenius

Auch wenn es in der heutigen Literatur manchmal als Muster bezeichnet wird, ist es kein echtes, weil es viel zu schwammig ist und damit ist sehr vielen Variationen zu finden ist, damit gibt es eigentlich kaum wiedererkennungswert

Selbst Architekturmuster müssen einigermassen konkret sein, ist aber bei MVC nicht der Fall, man erinnere sich nur an die Diskussion über unseren FAQ Beitrag.

 

[Ebenius]

Auch wenn es in der heutigen Literatur manchmal als Muster bezeichnet wird, ist es kein echtes, weil es viel zu schwammig ist und damit ist sehr vielen Variationen zu finden ist, damit gibt es eigentlich kaum wiedererkennungswert

Wie ist das mit MVA? Meiner meinung nach genau wie MVC ein Architekturmuster. Die Schichtenmodelle (two-tier, three-tier) sind auch Architekturmuster und meiner Meinung nach genauso schwammig wie MVC. Ich glaub, Architekten sind Künstler und mit entsprechender Freiheit sind deren Muster definiert. *gg*

[…]man erinnere sich nur an die Diskussion über unseren FAQ Beitrag.

Erinnere mich bloß nicht. :-D Rührte aber auch von einer Menge Unverständnis, auch von meiner Seite. Und oft trägt das falsche Verständnis des Wortes Modell zum Problem bei. Mir hatte die Diskussion damals allerdings viel genützt.

Aber egal, ob nun der Begriff Architekturmuster streitbar ist oder nicht; ich würde nicht im Forum kommentarlos behaupten es sei keines. Gerade bei den vielen Studenten hier führen solche Kommentare eher zu unverständnis, sobald der Prof als gerade MVC als Beispiel für ein modernes Architekturmuster anbringt. :-D

Ebenius

 

[maki]

Wie ist das mit MVA? Meiner meinung nach genau wie MVC ein Architekturmuster.

Müllverbrennungsanlage?
k.A. was MVA ist...

Die Schichtenmodelle (two-tier, three-tier) sind auch Architekturmuster und meiner Meinung nach genauso schwammig wie MVC.

Ein 2 Schichtenmodell gab es nie wirklich, wurde einfach nur Client-Server genannt und erst nachdem die N-Tier Architekturen aufgetaucht sind, sind umbenannt worden um noch Aufmerksamkeit zu finden & aktualität vorzugaukeln (zB. von IBM for Lotus Domino 4)

3 Schichtmodelle sind übrigens allesamt 4 Schichtmodelle(man denke nur a das externe System wie zB. eine DB), es soll mal jemanden gegeben haben der das mathematisch bewiesen hat...
Abgesehen davon sind 3 Schichtmodelle imho um einiges konkreter als MVC, Presentation, Logic, Integration, da weiss man zumindest was wohin gehört (für den fall das ich wen verwirrst habe: MVC gehört in die Presentation Schicht), auch wenn es sich nur um eine Trennung nach technischer Infrastruktur handelt.
Das ist bei MVC anders, Controller findet man oft in der View, aber auch ausserhalb, und je nach Technologie sind View & Controller auch noch weiter getrennt, siehe WebApps.
Der Begriff MVC "Paradigma" ist leider in der Fachliteratur imho fälschlicherweise durch MVC Pattern/Muster ersetzt worden, mit negativen konsequenzen.

Erinnere mich bloß nicht. Rührte aber auch von einer Menge Unverständnis, auch von meiner Seite. Und oft trägt das falsche Verständnis des Wortes Modell zum Problem bei. Mir hatte die Diskussion damals allerdings viel genützt.

Bei "echten" Mustern gibt es viel weniger Diskussionspotential, weil sie klarer sind.

Aber egal, ob nun der Begriff Architekturmuster streitbar ist oder nicht; ich würde nicht im Forum kommentarlos behaupten es sei keines. Gerade bei den vielen Studenten hier führen solche Kommentare eher zu unverständnis, sobald der Prof als gerade MVC als Beispiel für ein modernes Architekturmuster anbringt

Naja, kommentarlos hab ich es ja jetzt nicht mehr behauptet, oder?

 

[Ebenius]

Müllverbrennungsanlage? k.A. was MVA ist...

Wikipedia::Model-view-adapter

Naja, kommentarlos hab ich es ja jetzt nicht mehr behauptet, oder?

So ist's super.

Der Rest ist streitbar, aber ich würde höchstens aus Prinzip die Gegenseite vertreten. Das erspare ich uns; schließlich will ich ja den heutigen Internationalen Hurentag nicht entweihen. :lol:

Ebenius

 

[maki]

Das Thema ist eben nicht neu aber dafür umstritten, der engl. Wikipedia Artikel beginnt ja nicht umsonst mit den Worten:

Model–View–Controller (MVC) is a software architecture[1], currently considered an architectural pattern used in software engineering.

Die anderen Artikel die ich gefunden habe behaupten zwar ohne Einschränkung dass MVC ein Pattern wäre, sind aber nicht konform mit den Wikipedia Qualitätsstandards

Das erspare ich uns; schließlich will ich ja den heutigen Internationalen Hurentag nicht entweihen.

Ahh... endlich weiss ich was ich heute Abend mache