Verwirrung bzgl. Architekturen

[Guest]

Hallo,

bin ein wenig verwirrt im Zusammenhang mit möglichen Architekturen von Java Web-Anwendungen:

Soweit bin ich:

Zugrunde liegt dem im Prinzip immer eine Client Server Architektur. Die Webanwendung wird in mehreren Schichten (multi-Tier) aufgeteilt. Es gibt 2-Tier, 3 Tier, 4-Tier...
Eine 2-Tier Architektur habe ich zum Beispiel dann, wenn ich dem Client (Browser) eine statische HTML-Seite präsentiere.

Doch jetzt kommen meine Zweifel:

Wann habe ich eine 3-Tier bzw. 4-Tier Architektur? Worin besteht der Unterschied? Habe mehrere Bücher dazu gelesen und habe den Eindruck, dass in manchen die 3-Tier Architektur als 4-Tier Architektur bezeichnet wird und umgekehrt.

Und wo habe ich in diesem Zusammenhang MVC bzw. MVC Modell2 einzuordnen?

Vielen Dank schonmal...

Gruß,
Dennis

 

[Guest]

Ich bins nochmal... Bin immer noch am grübeln...

Ist es denn richtig, wenn ich behaupte, dass eine 3-Tier Archtiektur nicht mit dem MVC Prinzip gleichzusetzen ist, da bei einer 3-Tier Architketur niemals die Präsentationschicht mit der Datenschicht kommuniziert, die jedoch beim MVC der Fall ist, da hier der view direkt vom modell geupdatet wird?

Gruß,
Dennis

 

[SnooP]

nee nich wirklich... bei mvc ist ja die verknüpfung mit dem modell nicht direkt gegeben - da besteht ja auch immer entsprechendes "glueing", damit das funktioniert und damit die view halt gerade nicht auf das modell zugreifen kann...

3-Tier und 4-Tier ist nicht wahnsinnig verschieden... bei der 4-Tier wird... müsste nachgucken - meines Wissens in der 1. und 2. Schicht nochmal unterschieden, sprich Browser - Webserver - Applicationserver (Business-Logic) - Database... manche sagen dann Browser/Webserver ist eine Stufe... de fakto ist es das aber in der Praxis gerade nicht - die Anwendung im Webserver bereich sollte man halt nicht vernachlässigen

 

[Guest]

Demnach ist 3-Tier und 4-Tier im Prinzip dasselbe, nur mit dem Unterschied, dass bei der 4-Tier zwischen die "Präsentation" auf Client (Browser) und Webserver gesplittet wird und bei der 3-Tier dies zusammenhängend betrachtet wird.

Eine Tomcat-Anwendung kann man demnach als 3-Tier oder 4-Tier verstehen, je nachdem, ob man die Präsentation ncohmal gesplittet betrachtet. Der Tomcat ist dabei der Webserver und gleichzeitig der Anwendungsserver mit der Geschäftslogik.

Ist das so richtig?

Wo habe ich dann MVC einzuordnen?

Gruß und danke schonmal

 

[schalentier]

Also meiner Meinung nach bedeutet n-Tier einfach nur, dass es n verschiedene Systeme gibt, die irgendwie miteinander kommunizieren muessen. Wie das dann genau aussieht, hat damit eigentlich nichts zu tun.

Hast du also eine fertige Anwendung, musst du die einzelnen Systeme zaehlen und hast das "n".

Demnach waere: Browser - Tomcat - DB eine 3-Tier-Architektur

siehe auch Wikipedia...


MVC hat mit der Architektur an sich eigentlich nicht viel gemeinsam. MVC ist ein Pattern, also ein Muster, eine Vorlage, wie man eine Anwendung aufbauen koennte, um verschiedene Vorteile nutzen zu koennen. Man kann jede n-Tier Architektur nutzen, um eine Anwendung mittels MVC zu entwickeln.

Zudem kann man bei MVC sehr viel diskutieren... zb. bin ich der Meinung, dass es Quark ist, zu behaupten, der View duerfe nicht auf das Model zugreifen. Warum net? Andersrum sollte klar sein, das Model sollte niemals etwas ueber einen View wissen, aber der View stellt doch die Daten aus dem Model dar, warum also sollte er nicht auf das Model zugreifen koennen, sondern muss immer den Weg ueber den Controller gehen? IMHO is das Unsinn, deswegen: MVC ist nur ein Pattern, keine reale Architektur...

 

[Roar]

so schwierig is das doch nich:

 

[SnooP]

Also meiner Meinung nach bedeutet n-Tier einfach nur, dass es n verschiedene Systeme gibt, die irgendwie miteinander kommunizieren muessen. Wie das dann genau aussieht, hat damit eigentlich nichts zu tun.

Nein.. wenn ich 4 Rechner nebeneinander stelle die alle miteinander reden ist das noch lange nicht eine n-tier Anwendung. Tier heißt ja numal sowas wie Schicht oder Ebene und so sollte man das auch sehn...

Demnach waere: Browser - Tomcat - DB eine 3-Tier-Architektur

Genau... aber auch hier sind es nicht drei Rechner sondern 3 Tiers... sprich z.B. 1000 Clients mit Webbrowser - zwei Webserver auf der Tomcat-Seite wegen Loadbalancing und dazu noch 4 DB-Replikationsserver...

MVC hat mit der Architektur an sich eigentlich nicht viel gemeinsam. MVC ist ein Pattern, also ein Muster, eine Vorlage, wie man eine Anwendung aufbauen koennte, um verschiedene Vorteile nutzen zu koennen. Man kann jede n-Tier Architektur nutzen, um eine Anwendung mittels MVC zu entwickeln.

Joah... hmm... okay.

Zudem kann man bei MVC sehr viel diskutieren... zb. bin ich der Meinung, dass es Quark ist, zu behaupten, der View duerfe nicht auf das Model zugreifen. Warum net? Andersrum sollte klar sein, das Model sollte niemals etwas ueber einen View wissen, aber der View stellt doch die Daten aus dem Model dar, warum also sollte er nicht auf das Model zugreifen koennen, sondern muss immer den Weg ueber den Controller gehen? IMHO is das Unsinn, deswegen: MVC ist nur ein Pattern, keine reale Architektur...

Wenn du sagst, dass es Quark ist, das ein Modell nicht auf die View zugreifen darf, dann lehnst du MVC aber komplett ab - denn das ist ja nunmal ein wesentliches Bestandteil dieses Konzepts. Die Idee ist, dass grundsätzlich alle Schichten voneinander getrennt werden. Wenn ich eine View-Komponente habe, die direkt auf ein Modellobjekt zugreift, dann bin ich schon auf der View-Seite an bestimmte Dinge gebunden... eine View sollte also immer nur so viel wissen, wie es auch darstellt und nicht mehr, sonst hat man irgendwann das Problem, dass man das Modell verändert und auch die View wieder ändern muss... sicher muss man das dann manchmal sowieso, weil sich semantisch so viel verändert hat, dass die View keinen Sinn mehr ergibt - aber häufig halt auch nicht

Im Einzelfall kann man natürlich immer noch entscheiden, ob es nicht manchmal sinnig ist, ein Interface des Modells direkt in der view zu verwenden... kommt halt darauf an.

 

[schalentier]

Jo, du hast vollkommen Recht. Der Begriff System, den ich verwendet habe, ist aeusserst ungluecklich gewaehlt.

Ob aber "Schichten" das ganze besser erklaert... keine Ahnung. Irgendwann hab ich mal in einer Vorlesung ueber Softwaretechnologie gelernt, dass es 4 Arten von Schichten gibt, nach denen man eine Software aufteilen kann: :meld:
- Architekturschicht (von denen reden wir hier)
- Technische Schicht (Rechner, Cluster, Netzwerk, etc.)

Die andren beiden fallen mir grad net ein. Aber ich glaub es waren 4.. :bahnhof:


Zum MVC: Nein ich lehne nicht MVC komplett ab. Einzig die Sache eben, dass der View nicht auf das Model zugreifen koennen soll.

Dabei spreche ich von dem praktischen Teil einer MVC Implementierung. Wie soll denn diese Sache da realisiert werden? Im Grunde muessen alle Daten vom Model in den Controller geladen werden, damit der View die dann vom Controller lesen kann... und genau das ist IMHO doppelt-gemoppelt. Klar, man kann das generieren, oder man kann irgendwelche Transfer-Objekte generieren... aber wozu? Wenn sich am Model was aendert, MUSS der View angepasst werden, so oder so. Setzt man MVC "klassisch" um, muss man sogar zusaetzlich noch den Controller aendern.

Defacto kenn ich auch kein Framework, was den Zugriff des Views auf das Model tatsaechlich unterbindet. Meistens greift man auf ein Interface des Models zurueck. Oder auf das Datenobjekt selbst. Oder seh ich da was falsch?

 

[KSG9|sebastian]

Ähm...die Abhängigkeit View -> Model sollte auf jeden Fall vermieden werden. Das nächste Problem bei der Abhängigkeit ist, dass man aus versehen mal ein bisschen Viewlogik in das Model einbaut. Und spätestens dann hat man kein MVC mehr.

Ich versteh auch dein Problem nicht, und doppelt gemoppelt ist da auch nichts.

-View gibt die Daten über einen Event an den Controller, der kloppt es dann an die DB
-Bei nem Modelchange feuert der Controler nen Event auf den die View hört

Was ist daran doppelt gemoppelt?

Gruß

 

[Guest]

Zu MVC.

Eigentlich recht simpel,
wir haben das Model, ein einfache Pojo welches z.B. Observable implemenitert.
Die View kann sich beim Model anmelden und bekommt so mit welche Daten geändert werden und kann eben die Daten darstellen.
(Durch das Observable Pattern braucht das Model View nicht zu kennen und man kann meherere Views an ein Model andocken)
Die View kann auf den Controler zugreifen und der Controler ändert das Model.

Das Ganze stellt somit eine Art Kreis dar:
View kann Controler nutzen, Controler ändert Model, Model benachrichtigt View.

 

[Tellerrand]

Login vergessen ...

EDIT:
Hier wird öfters davon geredet die View dürfte nur über den Controler von Änderungen am Model erfahren und das ist so eine Sache.
Das Model sollte ohne die View zu kennen diese über Änderungen benachrichtigen, weshalb man eben zu Klassen wie Observable greift.

 

[schalentier]

Das Model muss einen Event an den Controller schicken, wenn sich etwas (zb durch irgendeinen anderen Controller) am Model aendert. Der Controller schickt es dann an den View. Also ist dieses Event doppelt (Model->Controller und Controller->View) vorhanden (im schlechtesten Fall sind es sogar 2 verschiedene Events, also zb. ModelChangeEvent und ControllerChangeEvent).

Man koennte natuerlich das Model zu einem reinen Datenmodel degradieren und alle Businessmethoden und -logik an die Controller haengen. Aber da wird mMn das schoene OO Design (ich hab Businessobjekte, mit Attributen und Operationen fuer die Logik) total aufgeweicht.

Zusaetzlich werden Unittests schwieriger, da Businesslogik auf diese Art und Weise nur mit den Controllern getestet werden kann, die aber eine deutlich hoehere Kopplung haben (der ganze Kommunikationsapparat), als reine Businessobjekte.

Irgendwie hab ich da scheinbar ein paar Verstaendnisprobleme... kennt jemand ein gutes Tutorial/Paper/Buch wo eine "richtige" MVC Architektur umgesetzt wird? Also nicht nur das theoretische Gelaber, sondern was pragmatisches... ;-)

 

[Tellerrand]

Man koennte natuerlich das Model zu einem reinen Datenmodel degradieren und alle Businessmethoden und -logik an die Controller haengen. Aber da wird mMn das schoene OO Design (ich hab Businessobjekte, mit Attributen und Operationen fuer die Logik) total aufgeweicht.

Wo die BL(Buisness Logic) liegt ist für MVC irrelevant.
Selbst wenn diese im Model liegt feuert das Model Events an die View, damit diese darauf reagieren kann.
Der Controler ist quasi die Schnittstelle um Operationen durch zu führen.
Ob der Controler direkt durch die View angesprochen wird oder durch andere Schichten sei mal dahingestellt, nur eines gillt, der Controler sollte die View nicht kennen.

Das Model muss einen Event an den Controller schicken, wenn sich etwas (zb durch irgendeinen anderen Controller) am Model aendert. Der Controller schickt es dann an den View. Also ist dieses Event doppelt (Model->Controller und Controller->View) vorhanden (im schlechtesten Fall sind es sogar 2 verschiedene Events, also zb. ModelChangeEvent und ControllerChangeEvent).

Ich finde nicht, dass der Controler über Änderungen am Model informiert werden muss, Controler != BL und Controler steuert nicht die View.

Irgendwie hab ich da scheinbar ein paar Verstaendnisprobleme... kennt jemand ein gutes Tutorial/Paper/Buch wo eine "richtige" MVC Architektur umgesetzt wird? Also nicht nur das theoretische Gelaber, sondern was pragmatisches... ;-)

Das Problem ist, dass man MVC durch viele verschiedenen Ansätzen umsetzen kann.
Eine einheitliche Definition gibt es leider nciht und bisher habe ich keine zwei Beispiele gesehen in denen MVC jeweils identisch umgesetzt wurde.
Allerdings gibt es fast bei jedem Buch ein Kapitel über MVC.

 

[schalentier]

Na du bist doch offensichtlich der gleichen Meinung wie ich @Tellerrand.

Es ist doch egal, ob der View auf Properties des Models zugreift, oder von diesem per Events informiert wird (egal aus dem Blickwinkel der Sichtbarkeit der 3 Komponenten untereinander).


Diese typischen MVC-Kapitel in Buechern kenn ich, aber da tauchen irgendwie mehr Fragen auf, als beantwortet werden...

 

[Tellerrand]

Ich denke auch das wir uns einig sind, mein Post ging eher auf andere hier ein.
Denn solche Aussagen

Ich versteh auch dein Problem nicht, und doppelt gemoppelt ist da auch nichts.

-View gibt die Daten über einen Event an den Controller, der kloppt es dann an die DB
-Bei nem Modelchange feuert der Controler nen Event auf den die View hört

beschreiben ein reines Schichtenmodel View, Controler, Model und eben nicht MVC im klassischem Sinne.
MVC ist eben kein Schichtenmodel indem View nur über den Controler Kontakt zum Model hat.

Es ist doch egal, ob der View auf Properties des Models zugreift, oder von diesem per Events informiert wird (egal aus dem Blickwinkel der Sichtbarkeit der 3 Komponenten untereinander).

Es ist schon egal, nur wenn View nicht mitbekommt das sich Daten ändern müsste man pullen, also in Intervallen schauen ob sich Daten geändert haben, was sehr ungünstig ist.
Und eine View die nicht auf Datenänderungen reagiert kommt bei MVC eigentlich nicht vor


Und ja die typischen Bücher werfen mehr Fragen in den Raum als Antworten, aber imho geht das nicht anderst :/

 

[schalentier]

Es ist doch egal, ob der View auf Properties des Models zugreift, oder von diesem per Events informiert wird (egal aus dem Blickwinkel der Sichtbarkeit der 3 Komponenten untereinander).

Es ist schon egal, nur wenn View nicht mitbekommt das sich Daten ändern müsste man pullen, also in Intervallen schauen ob sich Daten geändert haben, was sehr ungünstig ist.
Und eine View die nicht auf Datenänderungen reagiert kommt bei MVC eigentlich nicht vor

Ja schon richtig, aber z.b. bei einer ganz normalen Webanwendung gibts keine Events, wie vielleicht bei Swing. Da ist es am einfachsten, wenn sich der View einfach die Daten aus dem Model holt (also z.b. wenn man im jsp auf die Modelobjekte zugreifen kann).

 

[SnooP]

Frameworks die MVC umsetzen? Nunja... wie wär's mit Struts, JSF oder auch Cocoon? Jetzt nur auf der Webanwendungsseite...

sicherlich kann man bei Struts auf DTOs verzichten... da man aber auch dort ActionForms hat, ist die Modellschicht wieder abstrahiert, wenn man konsequent diese Forms nimmt... und in Struts gibts netterweise auch nen Tool mit dem man Werte aus einer Bean kopieren kann, so dass die Übertragung von Werten aus Modellbeans in Forms vereinfacht wird...

bei klassischen Client-Anwendungen gibts ja mehrere Konzepte für die Benachrichtigung... entweder klassisches Observer-Prinzip oder halt Event-Geschichten oder auch PropertyChangeListener... wenn man das gut kapselt, dann kann da viel auch automatisch aktualisiert werden...

Schicht ist übrigens auch schlechte Übersetzung - aber bei Tier weiß ja auch eigentlich jeder was gemeint ist - manchmal sind Anglizismen also doch sinnvoll