MVC Frage



  • Servus,
    kennt der View den Controller?

    danke im voraus!



  • Ja.



  • also ist sowas legitim?:

    View * view = new View(new Model());
    view->setController(controller);
    
    view.cpp
    
    void View::action()
    {
        controller->changeModel();
    }
    


  • Nein. Wieso sollte der View was am Controller ändern? IMHO muss der den Controller auch nicht kennen, wohl aber umgekehrt.



  • die View ändert ja auch nichts am Controller sondern sagt ihm nur das er was ändern soll



  • Dirk04! Ist schon richtig wie du das gemacht hast. Weil, irgendwo muß ja was referenziert sein.

    Wobei du schon einen Schönheitsfehler drin hast. Du änderst zwar nichts am Controller (was auch korrekt ist!), aber du sagst etwas den Models (plural!) über den Controller. Und das ist unglücklich. Normalerweise gibt es ja pro View-Objekt (Textbox o.ä.) ein bestimmtes Model. Also, warum sagt das View-Objekt nicht _direkt_ dem zugehörigen Model, das und vorallem was sich geändert hat?

    void View::action()
    {
        model->change();
    }
    

    Den Controller würde ich nur einem Container-View (z.B. Fenster) bekannt machen, weil normalerweise die Models im Controller liegen.

    +------------+
                     |   Model    |
                     +------------+
                    /\ .          /\
                    / .            \
                   / .              \
                  / .                \
                 / \/                 \
          +------------+ <------ +------------+
          |    View    |         | Controller |
          +------------+ ......> +------------+
    

    Das View kennt das Model, und kann dessen Daten ändern.

    Model kennt den View, sagt ihm aber nur, ob sich Daten geändert haben - nicht mehr!

    Das View kennt den Controller, weil darin normalerweise die Models instanziert liegen. Spricht aber normalerweise keine Controller-Funktionen an.



  • Achja, wegen dem Controller:

    void Fenster::setController(Controller *c)
    {
      this->controller = c;
    }
    
    void Fenster::initViews()
    {
      textBox.setModel(controller->getTextModel());
    }
    

    Da ein Fenster auch eine View ist, kennt es den Controller. Aber jede einzelne TextBox (die auch Views sind) müssen den Controller nicht kennen, denen reicht das Model.

    Ist sicherlich eine Designfrage, wie man wie an die Models usw. rankommt. Aber vom Prinzip her gilt die obige Deisgn-Skizze. 😃



  • Artchi schrieb:

    Das View kennt das Model, und kann dessen Daten ändern.

    Hallo Artchi,
    bist du dir da sicher?
    ich habe nämlich bei oracle.com das über das mvc das gelesen:
    http://otn.oracle.com/oramag/webcolumns/2003/techarticles/images/mills_mvc_f3.gif
    und hier ändert der controller das model.

    Grüße



  • Hier das Pattern von SUN:

    http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif

    Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.

    View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.

    Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

    Die View stellt einmal die Daten des Models dar (klar), weil es zu jeder View ein Model gibt. Und wenn der User z.B. in einer TextBox einen Buchstaben eingibt, wird dieser Buchstabe in das Model hinzugefügt.

    Zum Controller: der User klick auf einen Button (View), dieser gibt das an das Model weiter, dieses Model informiert den Controller. Den Controller gibts für mehrere Models.

    So lässt sich das ganze aus den von mir unterstrichenen Textstellen interpretieren.



  • also das pattern an sich gibts ja mittlerweile in vielen, vielen Versionen, bzw. "Interpretationen".
    Ich habe diesbezüglich auch schon gesehen, dass der Controller zwischen Model und View vermittelt, also sich die beiden gar nicht kennen. Dies ist aber meines Erachtens nicht so sinnvoll, da der ja dann wohl Daten einfach weiterreicht.
    Es gab schon welche, bei denen es nur einen Controller für alle Views gab und auch schon welche bei denen jeder View seinen Controller hat.

    Ich bin aber der meinung, dass das Model den View nicht kennen muss/soll.

    Wir haben mal MVC so implementiert, dass unser Model die eigentliche die Applikation war. Die anzuzeigenden Daten waren in einer Klasse gekapselt.
    Eine der "Core"-Klassen hat einen (also ein Controller für alle!) Controller instanziiert, welcher eine Referenz auf das Datenobjekt bekam und immer über updates der Daten informiert wurde. Jetzt konnten sich beim Controller Views (zur Laufzeit, auch nachgeladene) registrieren die dann die Referenz auf das Datenobjekt bekamen und eben vom Controller über die Aktualisierung informiert wurden. Somit war das Model komplett unabhängig von den Views.
    Man muss allerdings auch noch dazu sagen, dass unsere Views die eigentlichen Daten nicht verändert haben. Eingaben wie Options, oder Parameter liefen dann von View über Controller zu der besagten "Core"-Klasse.

    Also Begründung für den Punkt, dass sich meiner Meinung nach Model den View nicht kennen sollte ist einfach der, dass es nicht die Aufgabe "enterprise data" ist irgendwelche Views zu verwalten.



  • meinereiner_unreg schrieb:

    also das pattern an sich gibts ja mittlerweile in vielen, vielen Versionen, bzw. "Interpretationen".
    Ich habe diesbezüglich auch schon gesehen, dass der Controller zwischen Model und View vermittelt, also sich die beiden gar nicht kennen. Dies ist aber meines Erachtens nicht so sinnvoll, da der ja dann wohl Daten einfach weiterreicht.
    Es gab schon welche, bei denen es nur einen Controller für alle Views gab und auch schon welche bei denen jeder View seinen Controller hat.
    Ich bin aber der meinung, dass das Model den View nicht kennen muss/soll.

    I agree! 🙂
    Ich habe gerade auf S. 128-144 im
    Pattern-orientierte Software-Architektur | ISBN: 3827312825
    nochmals nachgekuckt. Dort wird sowohl CMV als MVC im Sequenzdiagramm dargestellt. Wobei im letzteren View eine z.B. eine makeController Fkt. aufruft und C initalisiert.

    meinereiner_unreg schrieb:

    Wir haben mal MVC so implementiert, dass unser Model die eigentliche die Applikation war. Die anzuzeigenden Daten waren in einer Klasse gekapselt.
    Eine der "Core"-Klassen hat einen (also ein Controller für alle!) Controller instanziiert, welcher eine Referenz auf das Datenobjekt bekam und immer über updates der Daten informiert wurde. Jetzt konnten sich beim Controller Views (zur Laufzeit, auch nachgeladene) registrieren die dann die Referenz auf das Datenobjekt bekamen und eben vom Controller über die Aktualisierung informiert wurden. Somit war das Model komplett unabhängig von den Views.
    Man muss allerdings auch noch dazu sagen, dass unsere Views die eigentlichen Daten nicht verändert haben. Eingaben wie Options, oder Parameter liefen dann von View über Controller zu der besagten "Core"-Klasse.

    Hierbei sollte ich nur hinzufügen, dass Deine "Core-Klasse" in Fachkreisen auch Observer genannt wird.
    GoF S.287-300
    Entwurfsmuster | ISBN: 3827318629
    oder
    http://home.earthlink.net/~huston2/dp/observer.html

    cu

    P84


Anmelden zum Antworten