J2EE Architektur

[Generic1]

Hallo,

ich bin mir so ungefähr im klaren, wie man eine J2EE Architektur aufbaut, aber eben nur so ungefähr,
Kann man eine grobe Struktur so darstellen, bzw. was fehlt und was macht man anders?
Besten Dank,

 

[maki]

Du verwechselst da etwas.

MVC existiert nur in der Presentation Tier, sonst nirgends
Core J2EE Patterns: Patterns index page

 

[SlaterB]

Interpretationssache, auf
Model View Controller ? Wikipedia
gehts viel um 'Serverseitige Webanwendungen',
wobei dort zwar keine vom View getrennte Business-Schicht genannt ist, aber zumindest ein Model

 

[Generic1]

Aber Services, DAOs sind in der mittleren Schicht (Business- Schicht) und Services verwenden DAOs aber DAOs verwenden keine Services, kann man das mal so sagen?

 

[ARadauer]

Ich finde auch dass man eine große dreischichtige Serveranwendung als MVC bezeichnen kann..
und wenn mir jemand erzählt er hat eine kleine gui Komponente mit Darstellung, Modell und bisschen Controller Code und er nennt das MVC finde ich das auch nicht falsch...

Core J2EE Patterns: Patterns index page ist doch ein Scherz oder? Ich muss immer lachen, wenn ich über diesen Link stoße...
Komplexes nichtssagend BullshitBingo Gif... wer soll das Teil bitte verstehen?
Das ist so richtig beschreibend für die Probleme der J2EE Plattform!

 

[Deadalus]

Öhm meinst du jetzt wirklich die alte J2EE Plattform oder die aktuelle JEE-Plattform?

In der JEE-Spec gibt es eine Abbildung, die die Architektur einer Anwendung beschreibt. Ich hab dir mal das Bild in den Anhang gepackt.

 

[SlaterB]

Aber Services, DAOs sind in der mittleren Schicht (Business- Schicht) und Services verwenden DAOs aber DAOs verwenden keine Services, kann man das mal so sagen?

kann man so sagen,
hier mal lose einen Link den ich dazu gefunden habe
Spring MVC Web Framework
(das MVC bezieht sich hier aber wirklich nicht auf die DAOs,
da ist das Model auch nicht die echte Persistenz sondern kopierte aufbereitete Daten in der View-Schicht)

 

[byte]

Kann mich maki nur anschließen. DAO und Service Schicht haben auch in meinem Verständnis nix mit dem MVC Pattern zu tun, sondern beschreiben die Architektur der Anwendung. MVC ist ja nur die strukturelle Vorgehensweise, um die View an die Daten zu koppeln.

Hier mal das MVC Schaubild bzgl. Spring MVC:

Der Controller ist bei Java Webanwendungen idR an mind. ein Servlet gekoppelt, bei Spring MVC das DispatcherServlet (FrontController, ein gängiges JEE Pattern). Dieses delegiert Requests über einen oder mehrere HandlerMappings an einen konkreten Controller. Dieser Controller ruft idR Services auf, um Businesslogik anzusteuern bzw. Daten über die DAOs aus der DB zu laden oder zu speichern. Für gewöhnlich lesen Controller dann die Daten aus den Business Objekten aus, die der Service geliefert hat und erzeugen damit das Modell für die View. Über einen ViewResolver wird dann die View gerendert (z.B. eine JSP).

Wichtig ist halt bei einer solchen 3-Schicht-Architektur, dass die Schichten voneinander getrennt sind. Die Persistenzschicht (DAOs) wissen nix von einer Service-Schicht oder einer Web-Schicht (Controller, View). Die Service-Schicht kennt nur die DAO-Schicht. Die Web-Schicht kennt nur die Service-Schicht. usw.

 

[maki]

Ich finde auch dass man eine große dreischichtige Serveranwendung als MVC bezeichnen kann..

Wie gesagt, in einer Mehrschichtarchitektur existiert MVC ausschliesslich nur in der Präsentationsschicht, aber viele sehen das falsch, Fowler hat darüber in seinem Buch PAEE schon geschrieben

Wenn man natürlich keine Schichtenarchitektur/-trennung hat, geht MVC über die ganze "Suppe"

 

[SlaterB]

was ist denn MVC, was sind denn Pattern wenn nicht die Sicht von vielen Menschen?
niemand hat ein Anrecht oder die Definitionshoheit darüber,
was richtig oder falsch ist entscheidet die Mehrheit und auch nicht unterdrückbare Minderheiten zählen als Sicht dazu

 

[maki]

was ist denn MVC, was sind denn Pattern wenn nicht die Sicht von vielen Menschen?
niemand hat ein Anrecht oder die Definitionshoheit darüber,
was richtig oder falsch ist entscheidet die Mehrheit und auch nicht unterdrückbare Minderheiten zählen als Sicht dazu

Wie weit die Meinungen zu MVC auseinandergehen sieht man im übrigen an unserem FAQ Beitrag dazu

Es geht ja hier nicht um MVC im allgemeinen, sondern um MVC im Zusammenhang mit Schichtenarchitektur.
Tatsache ist, wenn ich MVC auf "alle Schichten" anwende habe ich keine Schichtentrennung mehr und damit keine Schichten-"Architektur"

MVC macht nur in der GUI Sinn, wo denn sonst?
Für die GUI ist in JEE(Schichtenarchitektur) ausschliesslich die Präsentationschicht zuständig, soviel zur Definition, da sind Mehrheiten/Minderheiten irrelevant.
In dem Link zu den J2EE PAtterns lässt sich das auch leicht entnehmen, da gibt es einen Frontcontroller (Das C in MVC) für die Präsentationschicht , und dann gibt es nochmal einen BusiniessController, für die Businessschicht.

 

[SlaterB]

MVC macht ebenso perfekt für die Schichtenarchitektur Sinn,
Model = Persistenz,
View alles oben, egal ob gerade HTML oder RMI-Client, austauschbar,
Controller die Logik-Klassen

dieses perfekte Dreifaltigkeit findet man überall, genauso meinetwegen Computer-Daten, Grafikkarte + Bildschirm als Anzeige,
nur weil irgendwo mal für ein bestimmtes Thema ein Begriff gefunden wurde, kann man ihn nicht überall anders verwehren,
keine Computerpatente!

Tatsache ist, wenn ich MVC auf "alle Schichten" anwende habe ich keine Schichtentrennung mehr und damit keine Schichten-"Architektur"

das sind Details, auf die man verzichten kann

 

[maki]

MVC macht ebenso perfekt für die Schichtenarchitektur Sinn,
Model = Persistenz,
View alles oben, egal ob gerade HTML oder RMI-Client, austauschbar,
Controller die Logik-Klassen

Was du da beschreibst ist kein Schichtenmodell SlaterB, und nebenbei bemerkt, Model != Persistenz, dafür gibt es eigene Schichten, Model ist Teil der Businessschicht, Persistenz eine eigene Schicht, wurde früher "Integration Tier" genannt.
Der klassische Aufbau :
Präsentation/GUI Tier -> Business/Application Tier -> Persistenz/Integration Tier

Wenn die GUI jetzt direkt auf die Persistenzschicht zugreift, hat man einen Bruch im Konzept, dann braucht man doch keine Schichten

das sind Details, auf die man verzichten kann

Da muss man auch auf das Detail "Schichtenarchitektur" verzichten

 

[SlaterB]

> Was du da beschreibst ist kein Schichtenmodell SlaterB, und nebenbei bemerkt, Model != Persistenz

was möchtest du sagen, dass man in einer Webanwendnung nicht nach View, Logik und Daten unterscheiden kann?
das macht doch keinen Sinn, selbstverständlich gibt es diese Bereiche,

Details wie dass die Daten-Schicht in Model-Klassen und Persistenz-Logik zerfällt sind dem untergeordnet, überall findet man Substrukturen,

> Wenn die GUI jetzt direkt auf die Persistenzschicht zugreift

wie gesagt, Details auf die man verzichten kann, das wird bei dieser Art MVC überhaupt nicht betrachtet,
wobei oft genug wirklich direkt mit dem Model gearbeitet wird, die Logik reicht einfach die Original-Objekte durch

 

[maki]

was möchtest du sagen, dass man in einer Webanwendnung nicht nach View, Logik und Daten unterscheiden kann?
das macht doch keinen Sinn, selbstverständlich gibt es diese Bereiche,

Details wie dass die Daten-Schicht in Model-Klassen und Persistenz-Logik zerfällt sind dem untergeordnet, überall findet man Substrukturen,

Eine Webanwednung ist noch keine JEE Schichtenarchitektur.
WebApp (Tomcat) -> JEE Server (Session EJBs)
Das ist was Sun unter JEE Schichtenarchitektur versteht.

> Wenn die GUI jetzt direkt auf die Persistenzschicht zugreift

wie gesagt, Details auf die man verzichten kann, das wird bei dieser Art MVC überhaupt nicht betrachtet,
wobei oft genug wirklich direkt mit dem Model gearbeitet wird, die Logik reicht einfach die Original-Objekte durch

Wie ich in meinem ersten Post hier schon sagte, da verwechselst du etwas
MVC ist keine Schichtenarchitektur, aber wenn es in einer Schichtenarchitektur eingesetzt wird, dann ausschliesslich in der GUI
Details die man weglassen kann? Jetzt machst du die Sache einfacher als möglich...

Der TS hat doch ganz klar nach J2EE Schichtenarchitektur gefragt, wo ist der Sinn nun die Schichten zu ignorieren und zu sagen "Alles MVC"?

 

[byte]

Irgendwie habe ich das Gefühl, Ihr redet aneinander vorbei.

Grundsätzlich ist es doch so, dass man JEE Anwendungen idR in Schichten einteilt. Eine Schicht ist für die Präsentation zuständig. Und dort wendet man MVC an. Woanders machts ja keinen Sinn.

Persistenzschicht -> Kommunikation mit DB
Serviceschicht -> Businesslogik, benutzt Persistenzschicht
Präsentationsschicht -> MVC, Controller benutzen Serviceschicht


Das ist die übliche Vorgehensweise.

 

[SlaterB]

@maki
> wo ist der Sinn nun die Schichten zu ignorieren und zu sagen "Alles MVC?

an welcher Stelle habe ich denn Schichten ignoriert?
ich sage die ganze Zeit, dass auch die Schichten einer Webanwendungen dem MVC-System entsprechen, wenn auch nur grob,
und als du auf eventuelle Detail-Widersprüche ansprichst (ich nehme an 'Model informiert View', was auf die Schichten natürlich nicht zutrifft),
sage ich dass diese Details wegfallen, nie würde ich die Schichten ignorieren, die sind die übergeordneste Struktur überhaupt

du nimmst viel zu viel an, etwa dass ich MVC in allen Details 100% einbaue, wieso?
ich bin da viel näher am Ursprungsthema, da geht es um Zitat 'grobe Struktur', um all die Details überhaupt nicht

1.
Schichten,
2.
MVC was hier bedeutet: eine Schicht/ Einheit für die Anzeige, eine für die Daten, eine für die Logik,
View nimmt Nutzerrequest an, leitet sie an Controller weiter, dieser ändert die Daten, die dann mehr oder weniger in die View zurückkommen,
ob transformiert oder nicht, ob vom Controller aus angestoßen oder auf andere Initiative,

das sind nicht 100% aller Details von MVC in einer GUI, aber sehr sehr viel von dem was man grundlegend unter dem Begriff MVC versteht
und das passt perfekt zu einer Webanwendung (wie an vielen Stellen)

 

[maki]

an welcher Stelle habe ich denn Schichten ignoriert?

Hier zB.:

MVC was hier bedeutet: eine Schicht für die Anzeige, eine für die Daten, eine für die Logik,

Sorry, aber das ist grundsätzlich falsch, wie schon beim TS, nochmals: Das ist kein Schichtenmodell.

MVC != Schichtenmodell

Man kann aber MVC in einem Schichtemodell verwenden...

Das ist kein Detail

 

[SlaterB]

hatte gar zwischendurch schon Schicht durch 'Schicht/ Einheit' ersetzt, um dem auszuweichen

möchtest du außer 'das ist falsch' auch noch inhaltlich darauf eingehen?
1.
ist es nicht so dass es bei MVC um drei, ich nenne es jetzt mal um all deinen Nachbesserungen aus dem Weg zu gehen, "abstrakte Teile" Model, View, Controller geht,
die sich, vielleicht nicht streng nach Vorschrift aber doch ziemlich deutlich in der View-Schicht, der Logik-Schicht und der Daten-Schicht einer Webanwendung wiederfinden,
ja oder nein?
(1. b. bitte auf ganz irrelevante exakte Bezeichnungen der Schichten und Verweise von xy-Sun Spezifikationen verzichten)

2.
ist es nicht so, dass das Grundparadigma von MVC, View nimmt Request entgegen, leitet ihn an Controller weiter, der ändert Model, geänderte Model-Daten werden in der View wieder angezeigt, vollkommen zutrifft (edit: und zwar auf all die Schichten bezogen)?
ja oder nein

> MVC != Schichtenmodell

Schichtenmodell benimmt sich wie MVC ohne dabei seine Schichten aufzugeben..

 

[maki]

möchtest du außer 'das ist falsch' auch noch inhaltlich darauf eingehen?

Du nimmst zwei unabhängige Begriffe und setzt sie gleich, MVC hat keine Schichten und ist auch kein Schichtenmodell, kann aber in einem Schichtenmodell eingesetzt werden.

Denke nicht dass die Diskussion so Sinn ergibt.

 

[SlaterB]

nun gut, zumindest kein Widerspruch in den Kernaussagen,
für meinen Geschmack siehst du MVC extrem zu eng für den kleinen Bereich nur innerhalb der Präsentationsschicht,

hier noch ein Zitat von
Model View Controller ? Wikipedia

Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht.
Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die das gleiche Modell benutzt, aber einerseits eine Windows- oder Linux-Oberfläche realisiert, andererseits aber auch eine Weboberfläche beinhaltet.

mit Swing-Models kommt man da nicht weit, auf eine Webanwendung mit Datenschicht + Businesslogik völlig unabhängig vom Frontend passt der Satz aber perfekt

 

[Generic1]

Ok, was ich jetzt mitnehme ist, MVC nur in der GUI/Präsentationsschicht -> das erzeugen/einteilen in MVC wird z.B.: durch einen Frontcontroller unterstützt,
der FrontController verwendet die Service- Schichten der Businesslogik, der Frontcontroller ist also das Bindeglied zwischen Präsentationsschicht und Businessschicht.

Mit dem Model hab ich noch ein Problem, ein Model kann z.B.: eine Liste mit Objekten sein, in welchem sich Daten für die Präsentationsschicht(en) befinden?

Kann man das so darlegen?
Besten Dank,

 

[maki]

nun gut, zumindest kein Widerspruch in den Kernaussagen,
für meinen Geschmack siehst du MVC extrem zu eng für den kleinen Bereich nur innerhalb der Präsentationsschicht,

Nix für ungut SlaterB, aber du redest nur von MVC, nicht von Schichtenmodellen bzw. JEE Architekturen.
MVC und Schichtenmodelle haben eigentlich nix miteinander zu tun, können zwar komibinert werden, die beiden Begriffe sind aber nicht substituierbar.
Deswegen reden wir hier seit Stunden aneinander vorbei, hat nix damit zu tun wie ich MVC sehe, sondern damit wie du Schichtenmodelle nicht siehst

@Generic1
Soweit richtig, allerdings ist das "Bindeglied" das Remote Interface deiner SessionBean (Proxy), aber der Aufruf ist natürlich im Controller der GUI.

 

[Generic1]

Soweit richtig, allerdings ist das "Bindeglied" das Remote Interface deiner SessionBean (Proxy), aber der Aufruf ist natürlich im Controller der GUI.

Das versteh ich ehrlich gesagt nicht so ganz, könntest du das vielleicht nochmal ein bisschen genauer erklären?
Besten Dank

 

[SlaterB]

MVC und Schichtenmodelle haben eigentlich nix miteinander zu tun, können zwar komibinert werden, die beiden Begriffe sind aber nicht substituierbar.
Deswegen reden wir hier seit Stunden aneinander vorbei, hat nix damit zu tun wie ich MVC sehe, sondern damit wie du Schichtenmodelle nicht siehst

du wiederholst immer nur deine Aussage 'es ist nicht so' ohne irgendwelche Argumente,
falls du das nur machst um freundlicherweise überhaupt zu antworten, ist das ok,

mich überzeugen wird das aber kaum, da müsstest du auf den Inhalt eingehen,
ich sage ja schließlich auch nicht nur 'es ist so', sondern lege detailliert dar, wie die Elemente aufeinander passen und der Grundablauf tatsächlich stattfindet

 

[maki]

Das versteh ich ehrlich gesagt nicht so ganz, könntest du das vielleicht nochmal ein bisschen genauer erklären?
Besten Dank

Du holst dir das RemoteInterface der SessionEjb per JNDI und rufst da die Methoden auf, das kann aus einem Swing Client, einem Servlet oder von einem anderen Client aus passieren.
Das RemoteInterface der EJB ist sozusagen die Verbindung zum JEE Server.

 

[maki]

du wiederholst immer nur deine Aussage 'es ist nicht so' ohne irgendwelche Argumente,
falls du das nur machst um freundlicherweise überhaupt zu antworten, ist das ok,

mich überzeugen wird das aber kaum, da müsstest du auf den Inhalt eingehen,
ich sage ja schließlich auch nicht nur 'es ist so', sondern lege detailliert dar, wie die Elemente aufeinander passen und der Grundablauf tatsächlich stattfindet

Es würde helfen wenn du dir mal was zu Schichtenmodellen durchlesen würdest, ich sage dir seit x-Posts dass MVC und Schichtenmodelle nicht dasselbe sind, von dir kommt dann

MVC was hier bedeutet: eine Schicht/ Einheit für die Anzeige, eine für die Daten, eine für die Logik,...

:autsch:

Sorry, aber da gehe nicht auf den Inhalt ein, sonst diskutieren wir nur des diskutierens willen, wenn du wüsstest was Schichtenmodelle im Zusammenhang mit J(2)EE sind, würdest du nicht mehr diskutieren und sicherlich keine Begriffe "umbiegen".

 

[SlaterB]

es kommt von dir weiter keine inhaltliche Aussage, ich verstehe alles zu Schichten und MVC,
liefere Argumente um Argumente, aber du nimmst keine an noch gibts eigene,
da komme ich tatsächlich nicht weiter

'MVC was hier bedeutet' heißt wie MVC hier zu interpretieren ist, zum dritten Mal: etwas was 'Model' ist darf doch über 17 Ecken interpretiert mit einem Ding was man auch 'Model-Schicht' nennt in Verbindung gebracht werden,
wenn nicht einfach nur wegen der Namensgleichheit (das wäre wirklich zu kritisieren) sondern weil es inhaltlich in die Abläufe und die Abhängigkeiten passt,

ich diskutierte aus beiden Sichten nicht die exakte Definition (die sich bei MVC ja teils auf einen anderen Aspekt bezieht, daher gar nicht passen KANN) sondern wie es hier zusammenzubringen, wirklich fürs Verständis 'umzubiegen' ist, wenn man dazu gewillt ist,
das kannst du doch nicht völlig abkanzeln ohne jedes Argument

 

[byte]

Ich hab Euch doch schonmal gesagt, dass Ihr aneinander vorberedet. Maki bezieht sich auf 3-Schicht-Architekturen in verteilten Anwendungen (wonach der TE auch gefragt hat) und Slater redet offenbar von ganz generellen Schichtenmodellen.

@Maki: Du hast natürlich insofern recht, dass MVC nicht den 3 Schichten in einer verteilten 3-Schicht-Architektur entsprechen.

@Slater: Die Frage, ob man MVC auch als generelles Schichtenmodell abbilden kann, würde ich eher verneinen, weil hier das Prinzip der Dependency Inversion nicht gegeben ist. In einem Schichtenmodell sind die Abhängigkeiten zwischen den Schichten klar vorgegeben. Wenn Du nun M, V und C als Schicht betrachten willst, dann müsste man es zwangsweise so abbilden, dass C die oberste, V die mittlere und M die unterste Schicht ist. C kann also auf M und V zugreifen und V auf nur auf M (wobei es schon hier kein striktes Schichtenmodell mehr wäre, da C auch direkt auf M zugreifen kann). Da aber auch V auf C zugreifen muss, um Businesslogik zu triggern (z.B. durch Click auf Button), ist es kein Schichtenmodell.

 

[maki]

es kommt von dir weiter keine inhaltliche Aussage, ich verstehe alles zu Schichten und MVC,
liefere Argumente um Argumente, aber du nimmst keine an noch gibts eigene,
da komme ich tatsächlich nicht weiter

'MVC was hier bedeutet' heißt wie MVC hier zu interpretieren ist, zum dritten Mal: etwas was 'Model' ist darf doch über 17 Ecken interpretiert mit einem Ding was man auch 'Model-Schicht' nennt in Verbindung gebracht werden,
wenn nicht einfach nur wegen der Namensgleichheit (das wäre wirklich zu kritisieren) sondern weil es inhaltlich in die Abläufe und die Abhängigkeiten passt,

ich diskutierte aus beiden Sichten nicht die exakte Definition (die sich bei MVC ja teils auf einen anderen Aspekt bezieht, daher gar nicht passen KANN) sondern wie es hier zusammenzubringen, wirklich fürs Verständis 'umzubiegen' ist, wenn man dazu gewillt ist,
das kannst du doch nicht völlig abkanzeln ohne jedes Argument

Man kann alles über 17 Ecken interpretieren, aber irgendwann verlieren diese Interpretationen ihren Wert wenn man nicht dieselben Begriffe verwendet.

MVC ist eine reine GUI Kiste, Schichtenmodelle beziehen sich auch komplette Anwendungen.
Solange du MVC auf komplette Anwendungen beziehst nutzen wir nichtmal dieselben Begriffe für dasselbe bzw. dieselben Begriffe mit unterschiedlichen Bedeutungen.

`When I use a word,' Humpty Dumpty said in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.'

 

[SlaterB]

@byte
ich befinde mich auch im 3-Schichten-Modell und die Reihenfolge ist V, C, M,
wie kommt es denn bei dir zum Zwang auf C, V, M?
vielleicht meinst du als C den Front-Controller aus dem Bild deiner ersten Antwort in diesem Thread,
das ist für sich richtig, die Präsentationsschicht enthält ja für sich selber unbeschritten ein 'echtes' MVC,

aber eine Abstraktionsebene höher betrachtet:
das ganze Frontend mit Tomcat usw. Request-Annahme usw. ist V, die Präsentationsschicht,
austauschbar, könnte auch eine Swing-GUI sein was zeigt wie wenig ein Frontend-Kontroller auf dieser höheren Ebene
zu sagen hat, das ganze geht auch ganz ohne Tomcat

die Präsentationsschicht V steht ganz oben und wendet sich an C, die Businesslogik-Schicht,
diese kümmert sich um die Daten M und liefert diese an V zurück, direkt oder indirekt
wie mans dreht kann man nun meckern 'V greift gar nicht auf M zu, das ist kein MVC' oder
'V greift auf M zu, das sind doch keine sauberen Schichten',
wenn man es so eng sieht kann man sich wirklich davon verabschieden,

wieviel C in diesem Modell wirklich aktiv steuert/ steuern soll kann auch bezweifelt werden,
C ist hier ja überwiegend Businesslogik, was allgemein eher ein ungeklärter Bestandteil ist, Teil von M oder C,
aber C ist das Bindeglied zwischen V und M, prüft Zugriff, kann mit Exceptions oder sonstigen Hinweisen
die Ausgabe steuern usw.

@maki
wie gesagt,
"für meinen Geschmack siehst du MVC extrem zu eng für den kleinen Bereich nur innerhalb der Präsentationsschicht"
das ist ja noch eine Stufe davor, wenn du dich gar nicht auf die grundsätzliche Interpretation einläßt,
dann brauchst du dich ja um die anderen Dinge wie 'Schichten verletzt' nicht kümmern

 

[maki]

@maki
wie gesagt,
"für meinen Geschmack siehst du MVC extrem zu eng für den kleinen Bereich nur innerhalb der Präsentationsschicht"
das ist ja noch eine Stufe davor, wenn du dich gar nicht auf die grundsätzliche Interpretation einläßt, dann brauchst du ja um die anderen Dinge wie 'Schichten verletzt gar nicht kümmern

Ohne gemeinsame Sprache kann man nicht kommunizieren, wenn ich jetzt ein "Ja" als "Nein" interpretiere und ein "Niemals" als "Auf jedenfall" ist das nicht hilfreich für die Kommunikation.
MVC mag interpretiert werden, aber MVC als 3 Schichten zu interpretieren hilft keinem, denn das ist genau der Fehler und die falsche Wahrnehmung die es zu bekämpfen gilt solange es da noch so viele Missverständnisse gibt.

Kurz gesagt:
MCV = Apfel
Schichtenmodell = Birnen

Kann man beides essen und von beidem Blähungen bekommen, aber wenn ich einen Apfel will dann will ich keine Birne.
Dass es einen Apfel-Birnen Kuchen gibt ändert daran nix

 

[SlaterB]

wie gewohnt ohne jedes inhaltliche Argument,
dass es bei beiden eine View, ein Model und was dazwischen gibt,
dass es bei beiden generell um die Frage geht, wie ein Request bearbeitet wird, wie sich das Model ändert, woraus ein View dargestellt wird,
solche extremen gemeinsamen Fragen ignorierst du und sprichst von Äpfeln und Birnen,

das machst du dir sehr einfach

 

[byte]

ich befinde mich auch im 3-Schichten-Modell und die Reihenfolge ist V, C, M,
wie kommt es denn bei dir zum Zwang auf C, V, M?

Bei MVC im klassischen Sinne steuert doch der Controller die View. Beispiel (Richclient): Controller horcht auf Änderungen im Modell und triggert dann einen Repaint in der View. Beispiel (Webclient): Request kommt rein, Controller macht Berechnungen und triggert rendern der View (JSP). Der Controller muss also eine Abhängigkeit auf die View haben. Daher kommt V -> C -> M ja nicht in Frage. Und da liegt halt der Widerspruch, denn dann kann man aus V keine Businesslogik mehr in C triggern. Das geht nur wenn V <-> C und das ist im Schichtenmodell nicht möglich.

Der Rest ist mir jetzt zu abgefahren, da nicht mehr Präsentationsschicht-bezogen und da hört für mich das Verständnis von MVC auf.

 

[maki]

wie gewohnt ohne jedes inhaltliche Argument,

Du erkennst vielleciht die Argumente nicht wenn du die Begriffe anders deutest.

dass es bei beiden eine View, ein Model und was dazwischen gibt,
dass es bei beiden generell um die Frage geht, wie ein Request bearbeitet wird, wie sich das Model ändert, woraus ein View dargestellt wird,

Nein, Schichtenmodelle haben nicht notwendigerweise eine GUI/View, MVC dagegen immer.
Aber wenn ich sage dass MVC 'ne reine GUI Kiste ist per Definition, dann wird das nciht als Argument gewertet?
Du ignorierst doch schon seit x-Post meine Argumente und versuchst dann künstliche Gemeinsamkeiten zu finden...

solche extremen gemeinsamen Fragen ignorierst du und sprichst von Äpfeln und Birnen,

Diese "extremen" Gemeinsamkeiten siehst eben nur du mit deiner Einzelmeinung...

 

[SlaterB]

Bei MVC im klassischen Sinne steuert doch der Controller die View. Beispiel (Richclient): Controller horcht auf Änderungen im Modell und triggert dann einen Repaint in der View. Beispiel (Webclient): Request kommt rein, Controller macht Berechnungen und triggert rendern der View (JSP). Der Controller muss also eine Abhängigkeit auf die View haben.

die Abhängigkeit ist der Rückgabewert, der bestimmt was als nächstes angezeigt wird,

edit:

Beispiel (Webclient): Request kommt rein, Controller macht Berechnungen und triggert rendern der View (JSP).

Client sendet Anfrage x mit Parametern y,
Front-Controller liefert die Daten fast ungefiltert an Business-Logic-Schicht, diese liefert allgemein zurück was zu tun ist 'gehe zu Login', 'schreibe Vielen Daten für Bestellung'
-> je nachdem ob eine Swing-GUI oder ein Web vorne sitzt führt dies zu HTML- oder JOptionPane-Ausgaben, diese Details muss der Hauptcontroller der gesamten 3-Schichten nicht wissen,
das hat er an die View delegiert,
die View/ Präsentationsschicht zerfällt natürlich wiederum in das echte MVC, der Front-Controller sucht die richtige Jsp raus usw,
genauso wie in Swing irgendein Controller irgendwas machen würde,





-------
@maki

dass es bei beiden eine View, ein Model und was dazwischen gibt,
dass es bei beiden generell um die Frage geht, wie ein Request bearbeitet wird, wie sich das Model ändert, woraus ein View dargestellt wird,

Nein, Schichtenmodelle haben nicht notwendigerweise eine GUI/View, MVC dagegen immer.

es geht doch von Anfang an um das 3-Schichten-Modell einer Webanwendung, oben auf die Präsentationsschicht,
wie kann es da keine View geben?

Aber wenn ich sage dass MVC 'ne reine GUI Kiste ist per Definition, dann wird das nciht als Argument gewertet?
Du ignorierst doch schon seit x-Post meine Argumente und versuchst dann künstliche Gemeinsamkeiten zu finden...

entschuldige, 'nein, das ist kein MVC', 'MVC ist was anderes', 'MVC hat hier nix zu tun', 'Schichten gehen anders' usw. sind für mich keine inhaltlichen Argumente, überall fehlt das magische Warum,
ich gebe aber gerne zu dass du davon jede Menge schreibst, wollte ich nicht ignorieren,

solche extremen gemeinsamen Fragen ignorierst du und sprichst von Äpfeln und Birnen,

Diese "extremen" Gemeinsamkeiten siehst eben nur du mit deiner Einzelmeinung...

tja, soll ich einen mathematischen Beweis führen?
wer bei "Präsentation - Logik - Daten" zu "View - Controller - Model" keinen Zusammenhang erkennt?!
ich kann selbstverständlich nur meine Meinung wiedergeben

 

[maki]

es geht doch von Anfang an um das 3-Schichten-Modell einer Webanwendung, oben auf die Präsentationsschicht,
wie kann es da keine View geben?

Am Anfang war von Web nie die Rede (bis du damit angefangen hast), nur von J2EE Architektur. JEE ist ein Schichtenmodell, und letzteres muss nicht notwendigerweise eine GUI haben(WebServices zB. reichen für B2B), das hatte ich gesagt & gemeint, um den Unterschied zwischen Schichtenmodell und MVC deutlicher zu machen.
Der TS wollte wisen wo da die MVC Kiste reinkommt/reinspielt, das habe ich ihm gesagt.

entschuldige, 'nein, das ist kein MVC', 'MVC ist was anderes', 'MVC hat hier nix zu tun', 'Schichten gehen anders' usw. sind für mich keine inhaltlichen Argumente, überall fehlt das magische Warum,
ich gebe aber gerne zu dass du davon jede Menge schreibst, wollte ich nicht ignorieren,

Das erste was ich sagte: MVC exisitert nur in der Präsentationschicht, deine Antwort: Interpretationssache eines Wikipedia Artikels
Sorry, aber so läuft das nicht.
Manchmal kann man Dinge auch als gegeben nehmen und hinterfragen, aber nicht gleich "nee, alles interpretationssache und ich sehe das so..."

tja, soll ich einen mathematischen Beweis führen?
wer bei "Präsentation - Logik - Daten" zu "View - Controller - Model" keinen Zusammenhang erkennt?!
ich kann selbstverständlich nur meine Meinung wiedergeben

Kannst du gerne versuchen, wird auch falsch sein solange du dir die Schichtenmodelle nicht grundsätzlich verstanden hast..
Hab halt keine Lust auf Argumente der Form "Ich nenne alles Schichten was ich will" einzugehen, das Leben ist kein Ponyhof, wenn es allgemeingültige Definition von Begriffen gibt, dann hält man sich auch daran.

Mal ohne Jux & Dollerei: Die Frage nach MVC und Schichtenmodellen ist in Vorstellungsgesprächen sehr üblich wenn es um JEE Projekte geht, da sollte man schon wissen was man antwortet.

 

[SlaterB]

Am Anfang war von Web nie die Rede (bis du damit angefangen hast), nur von J2EE Architektur. JEE ist ein Schichtenmodell, und letzteres muss nicht notwendigerweise eine GUI haben(WebServices zB. reichen für B2B), das hatte ich gesagt & gemeint, um den Unterschied zwischen Schichtenmodell und MVC deutlicher zu machen.

im ersten Posting ist doch das 3-Schichten-Modell mit View (= Präsentationsschicht) vor dem Client, es ist doch klar worum es geht?

und dass die Präsentationsschicht weder Web noch GUI sein muss, sondern auch WebServices oder was anderes (ich hatte RMI erwähnt) ist doch auch gerade die ganze Zeit mein Argument?

Das erste was ich sagte: MVC exisitert nur in der Präsentationschicht, deine Antwort: Interpretationssache eines Wikipedia Artikels
Sorry, aber so läuft das nicht.

ist ja ok, bei dem Punkt waren wir schon 2x, du möchtest es nicht so betrachten

Kannst du gerne versuchen, wird auch falsch sein solange du dir die Schichtenmodelle nicht grundsätzlich verstanden hast..

dieses Seitenthema kannst du dir eigentlich ganz sparen,
was die Schichten sind war doch nie in Diskussion,
nur ob man diese Schichten auch als MVC betrachten kann,
wobei du dir herausnimmst, dass ich dann alle GUI-internen Konzepte von MVC zu übernehmen habe (direkte Interaktion, die die Schichten kaputt machen würde), ergo ich das Schichten-Prinzip verletzte,

das ist doch gar nicht so, ich stelle die Schichten ganz nach oben und MVC so weit, wie es machbar ist, eben z.B. nur über den Rückgabewert, die Business-Logik kann nicht direkt auf die View-Schicht zugreifen

das ist übrigens ein direktes inhaltiches Argument, während ich bei dir immer nur vermuten muss wie du dazu kommst dass ich was falsch verstehe,
einen deutlichen Satz wie von byte 'Controller kann nicht auf View zugreifen' hast du bisher nicht geliefert, so weit ich das zurückerinnere,
falls mir ein solcher Vergleich erlaubt ist

 

[Generic1]

Also das ich so eine Diskussion anzettle war mir nicht klar, Vielleicht könnte noch jemand schreiben was ein empfehlenswertes Buch zum Thema JavaEE- Architekuren ist. Ich lese gerade das Buch von Evans, aber das ist ziemlich steil (für mich), der Titel ist Domain Driven Design.

 

[maki]

DDD ist 'ne gute Sache, aber nicht unbedingt JEE.

Klassiker sind zB. Patterns für Enterprise Application-Architekturen: Amazon.de: Martin Fowler: Bücher und Core J2EE Patterns: Best Practicies and Design: Amazon.de: Deepak Alur, John Cupri, Dan Malks: Englische Bücher.

Letzteres ist veraltet, eben so wie J2EE, ersteres ist immer noch gültig/aktuell, aber keine leichte Kost

 

[mvitz]

Ansonsten kann ich noch empfehlen:

Real World Java EE Patterns Rethinking Best Practices: Amazon.de: Adam Bien: Englische Bücher