Model-View-Controller (MVC) Explained Through Ordering Drinks At The Bar

    Forum Unterstützen

    Wenn Du unsere Arbeit unterstützen möchtest, würden wir uns über eine Spende sehr freuen! :-)

    Team

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Mittwoch ist wieder Stammtisch in Berlin :-) Wir würden uns über einen Besuch freuen. Hier gibt's nähere Info's

      Model-View-Controller (MVC) Explained Through Ordering Drinks At The Bar

      Model-View-Controller (MVC) Explained Through Ordering Drinks At The Bar

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Si Vis Pacem“ ()

      wow... geile erklärung :thumbup:
      thinkpad W520: i7-2720qm, nVidiaQuadro1000m/intelHD3000, 16gbRam, 10.11.6/clover
      thinkpad X220: i5-2520m, intelHD3000, 16gbRam, 10.12.6/clover
      temporär: T420: i5-2540m, HD3000, 6gb, systemvorkoster

      ersthilfe vor ort für altes zeugs (-> laptops)
      8)

      berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD
      nächster Termin: voraussichtlich MITTWOCH der 19.9.2018, 19.00 Uhr
      Eine tolle Darstellung!

      Inhaltlich bin ich mir nicht sicher, ob ich wirklich komplett einverstanden sein kann, aber fast. Wie gesagt, die Darstellung ist sehr gut.

      Ich füge hier zum Vergleich zwei Darstellungen aus den Handbüchern von Smalltalk 80/ObjectWorks als Attachments an. Smalltalk 72 und später Smalltalk 80 waren die ersten Systeme, die dieses Pattern genutzt und quasi eingeführt haben. Die Darstellung in den Handbüchern ist ebenfalls hervorragend. Damals waren Bücher noch mehr oder weniger die einzige Möglichkeit Wissen zu übermitteln, aber das wisst Ihr ja..

      Es geht bei dem Muster im wesentlichen darum, Komponenten stecken zu können. Das war die ursprüngliche Idee. Daher ist der Controller fast immer auf den View abgestimmt, aber das Modell ist im Grunde ganz unwissend, wer es modifiziert und wie und warum. Es reflektiert die Änderungen einfach – übrigens fast immer synchron -, so dass beliebig viele Views (aka Observer) darauf reagieren können.

      View und Controller treten immer paarweise auf, weil der Controller die Nutzerinteraktion mit dem View ermöglicht (oder teilweise unterbindet, Stichwort "No Controller" oder "Read Only Controller").

      Die Controller selbst formen eine eigene Hiearchie, die in Smalltalk mit dem "Chain of Responsibility Pattern" umgesetzt worden ist. Diese Hierarchie erlaubt es beispielsweise, sämtliche Menü-Optionen (in Smalltalk auf der rechten, "blauen" Taste) aus den Views und ihren Super-Views zusammenzuziehen. Die Views sind ebenfalls in einer Hierarchie organisiert (Composite Pattern), die unabhängig von der Controller-Hierarchie ist.

      All das ist etwas aufgeweicht worden, als in den frühen Jahren Web-Frameworks ihre grundlegenden Muster mit MVC beschrieben. Mir fällt hierzu als Beispiel für ein frühes Framework Apache Struts ein.
      Bilder
      • MVC1.jpg

        953,95 kB, 2.000×1.500, 4 mal angesehen
      • MVC2.png

        397,91 kB, 700×363, 4 mal angesehen