Wieder einmal... ...MVC!

[klickverbot]

Hallo,

ich habe beschlossen, mich einmal näher mit dem MVC-Pattern auseinanderzusetzen und habe deswegen einmal versucht, mit Papier und Bleistift die Architektur eines einfachen Flash-Gästebuchs zu erstellen. Dabei bin ich auf ein paar konzeptionelle Schwierigkeiten gestoßen.

Angenommen ich habe ein abstraktes GuestbookModel, das implementierte Unterklassen wie z.B. XMLModel hat. Dieses Model wird von der "Hauptapplikation" erzeugt.
Des weiteren gibt es noch eine GuestbookView, die die Einträge anzeigt und einen GuestbookController, der die Eingaben von der View bekommt und verarbeitet.

• Was passiert, wenn der Benutzer einen neuen Eintrag erstellen will? Wahrscheinlich wird dann eine neue View erzeugt, weil ja auch die ganzen UI-Elemente usw. wechseln. Aber wer erzeugt die View? Das ganze wird ja dadurch ausgelöst, dass der Benutzer einen Knopf der View drückt, die dann das Ereignis an den Controller weiterleitet. Erzeugt dieser dann ein neues Controller-View-Paar?
• Was ist mit Sachen wie z.B. Captchas zur Spam-Verhinderung? Damit das GuestbookModel neue Daten am Server eintragen darf, muss der Benutzer ein Captcha lösen. Dieses Captcha muss von der View angezeigt werden und der Controller muss es verarbeiten (überprüfen).
  Andererseits passt das ganze Captcha ja nicht wirklich in das GuestbookModel, weil:
  1. Eine andere Implementation des Models, z.B. LocalDatabaseModel könnte ja die ganze Captcha-Authentifikation gar nicht benötigen.
  2. Von der Abstraktionsebene passt das Captcha nicht zum Rest des Models – das Captcha gehört ja weder zum Gästebuch noch zu einem spezifischen Eintrag.
  3. Wie erfährt die View, dass das Model eine Authentifikation benötigt?
• Was ist mit Fehlern, die bei Update bzw. Abgleich des Models mit der serverseitigen Datenbank auftreten? Werden die Views einfach über ein Ereignis darüber informiert? Eigentlich passt es ja genau so wenig zu der Abstraktionsebene. Oder kommen in das Model einfach alle Daten der Applikation hinein (was ich nicht glaube)?

Bleibt noch zu sagen, dass ich in Sachen MVC wirklich ein Neuling bin; ich habe auch in anderen Sprachen noch nie bewusst damit gearbeitet.
Nachdem ich gestern ein paar Stunden darüber nachgedacht habe, raucht mir noch immer der Kopf

EDIT: Mist, im falschen Forum gepostet, sollte natürlich nach Softwarearchitektur...

[Omega Psi]

Hm,

ich bin mir nicht so ganz sicher, wer von uns beiden nun durcheinanderkommt.

Ich würde zum Beispiel nicht von Views, Controller-View-Paar etc reden. Du hast einen View - diese View kann und soll verschiedene Daten anzeigen, aber auch eingeben udn an den Controller weitergeben.

Die View ist losgelöst vom Controller und vom Model. Und das Modell sind auch nur Daten.

Zu "wer erzeugt den View": Die Frage verstehe ich nciht ganz. Der Controller erwartet ja auch Eingaben vom View. Du musst deshalb nicht davon ausgehen, dass Komponenten erzeugt werden. Die einzelnen Komponenten kommunizieren über Schnittstellen/Protokoll. Du hast Verschiedene Arten Daten ein- und auszugeben.

Zu "Wie erfährt die View, dass das Model eine Authentifikation benötigt?": Das Modell braucht keine Athentification sondern der Controller, der die Daten verarbeitet innerhalb der Anwendung. Das Modell sind nur Daten.

Zu den Captchas: ich weiss net, was das genau ist, aber auch hier: Der Controller schickt eine Nachricht an die View, erwartet und bekommt einen Input und dann gehts weiter.

Das würde ich so zu deinem Anliegen beisteuern. Ich würde die Captchas vielleicht erstmal weglassen...

[klickverbot]

Zitat von Omega Psi

Hm,
ich bin mir nicht so ganz sicher, wer von uns beiden nun durcheinanderkommt.

Das liegt wahrscheinlich daran, dass mir noch nicht so ganz klar ist, wie MVC im Bezug auf eine Flash-Anwendung aussieht, die sowohl einen Client- als auch einen Server-Teil hat.

Es muss ja auch auf der Client-Seite eine Model-Klasse bzw. zumindest einen Model-Connector geben, die den Zugriff bzw. die Zwischenspeicherung der Daten vom Server-Teil (im Normalfall wahrscheinlich PHP+MySQL) kapselt. Oder ist das im Normalfall anders?

Zitat von Omega Psi

Das würde ich so zu deinem Anliegen beisteuern. Ich würde die Captchas vielleicht erstmal weglassen...

Ich will ja jetzt kein Programm coden (wer weiß, vielleicht wird aber noch was draus), sondern nur die Architektur auf Papier entwerfen und alle Probleme bzw. Fragen, die sich mir stellen, lösen. Es hat jetzt keinen Sinn wenn ich sage: Das Problem lasse ich jetzt einfach weg; ich werde sowieso nie MVC-Gästebuch programmieren, das eine Captcha-Überprüfung enthält. Die Implementierung ist sicher nicht mein Problem.

Zitat von Omega Psi

Ich würde zum Beispiel nicht von Views, Controller-View-Paar etc reden. Du hast einen View - diese View kann und soll verschiedene Daten anzeigen, aber auch eingeben udn an den Controller weitergeben.

Die View ist losgelöst vom Controller und vom Model. Und das Modell sind auch nur Daten.

Zu "wer erzeugt den View": Die Frage verstehe ich nciht ganz. Der Controller erwartet ja auch Eingaben vom View. Du musst deshalb nicht davon ausgehen, dass Komponenten erzeugt werden. Die einzelnen Komponenten kommunizieren über Schnittstellen/Protokoll. Du hast Verschiedene Arten Daten ein- und auszugeben.

Das ist mir schon klar. Aber sofern ich das Pattern verstanden habe, hat jede View auch ihren eigenen Controller.
Meine Frage war darauf bezogen, dass ich mir gedacht habe, für das Anlegen eines neuen Eintrags wäre eine eigene View gut. Nicht aus Abstraktions- o.ä. Gründen, sondern einfach, weil ich in einer nicht MVC-Application wohl auch zwecks Ordnung und Übersicht eine eigene Klasse erstellen würde. Vielleicht ist es aber auch besser, es gibt nur eine einzige View, die als Fassade für zwei Unterklassen dient. Was meint ihr?

Zitat von Omega Psi

Zu "Wie erfährt die View, dass das Model eine Authentifikation benötigt?": Das Modell braucht keine Athentification sondern der Controller, der die Daten verarbeitet innerhalb der Anwendung. Das Modell sind nur Daten.

Wenn man es so betrachtet, was rein auf das Problem bezogen auch logisch erscheint, dann hat man damit keine Probleme. Nur habe ich irgendwie automatisch angenommen, dass sich auf Server-Seite ausschließlich das Model-Backend befindet.
Wenn ich jetzt, was ja auch gescheiter ist, Server und Client für das Layout jetzt einmal komplett weg lasse und so tue, als ob das Ding eine einzige (PHP-)Anwendung wäre, dann gehört die gesamte Captcha-Behandlung natürlich in den Controller. Aber ich war einfach davon "geblendet", dass der Controller für die Captcha-Kontrolle auch einen Server-Teil braucht (sonst wäre das GB ja anfällig für Direktzugriff über HTTP)

Acja, Captchas sind z. B. die Bilder, die verzerrte Buchstaben enthalten, die du dann eingeben musst – bei Webanwendungen werden sie hauptsächlich dazu verwendet, (Spam-)Bots auszusperren.

[Omega Psi]

Zitat von klickverbot

Das liegt wahrscheinlich daran, dass mir noch nicht so ganz klar ist, wie MVC im Bezug auf eine Flash-Anwendung aussieht, die sowohl einen Client- als auch einen Server-Teil hat.

MVC sieht für alle Anwendungen gleich aus, sonst macht es keinen Sinn, das Ding als Designpattern zu netzen...

View im Flash sind die sichtbaren Aspekte... das, was auf der Bühne erscheint. Controller ist die Logik (ausgelagerter AS-Code vereinfacht die Anschauung)

Es muss ja auch auf der Client-Seite eine Model-Klasse bzw. zumindest einen Model-Connector geben, die den Zugriff bzw. die Zwischenspeicherung der Daten vom Server-Teil (im Normalfall wahrscheinlich PHP+MySQL) kapselt. Oder ist das im Normalfall anders?

Nein, das ist Konzeptionell nicht ganz richtig. Der Controller übernimmt auch die interne Umstrukturierung der Daten. Sonst hättest du 2 Modells und 2 Controller.

Ich will ja jetzt kein Programm coden (wer weiß, vielleicht wird aber noch was draus), sondern nur die Architektur auf Papier entwerfen und alle Probleme bzw. Fragen, die sich mir stellen, lösen. Es hat jetzt keinen Sinn wenn ich sage: Das Problem lasse ich jetzt einfach weg; ich werde sowieso nie MVC-Gästebuch programmieren, das eine Captcha-Überprüfung enthält. Die Implementierung ist sicher nicht mein Problem.

Captchaprüfung gehört zum Controller.

Das ist mir schon klar. Aber sofern ich das Pattern verstanden habe, hat jede View auch ihren eigenen Controller.
Meine Frage war darauf bezogen, dass ich mir gedacht habe, für das Anlegen eines neuen Eintrags wäre eine eigene View gut. Nicht aus Abstraktions- o.ä. Gründen, sondern einfach, weil ich in einer nicht MVC-Application wohl auch zwecks Ordnung und Übersicht eine eigene Klasse erstellen würde. Vielleicht ist es aber auch besser, es gibt nur eine einzige View, die als Fassade für zwei Unterklassen dient. Was meint ihr?

Nein, dann würde das anders aussehen. Dann würder jeder Controller auch ein eigenes Model in Anspruch nehmen können.

Ein neues Fenster ist eine Eigenschaft des Views, kein neuer View. Du verwechselst da was.

Wenn man es so betrachtet, was rein auf das Problem bezogen auch logisch erscheint, dann hat man damit keine Probleme. Nur habe ich irgendwie automatisch angenommen, dass sich auf Server-Seite ausschließlich das Model-Backend befindet.
Wenn ich jetzt, was ja auch gescheiter ist, Server und Client für das Layout jetzt einmal komplett weg lasse und so tue, als ob das Ding eine einzige (PHP-)Anwendung wäre, dann gehört die gesamte Captcha-Behandlung natürlich in den Controller. Aber ich war einfach davon "geblendet", dass der Controller für die Captcha-Kontrolle auch einen Server-Teil braucht (sonst wäre das GB ja anfällig für Direktzugriff über HTTP)

Server Logik + AS Logik bilden den Controller.

Acja, Captchas sind z. B. die Bilder, die verzerrte Buchstaben enthalten, die du dann eingeben musst – bei Webanwendungen werden sie hauptsächlich dazu verwendet, (Spam-)Bots auszusperren.

Ah, alles klaro, danke

[klickverbot]

Zitat von Omega Psi

MVC sieht für alle Anwendungen gleich aus, sonst macht es keinen Sinn, das Ding als Designpattern zu netzen...

Jaja, das ist mir schon klar. Was ich eigentlich damit meinte: Ich bin mir nicht ganz im Klaren darüber, wie sich die Interaktion mit dem Server in das MVC-Pattern einfügt...

Zitat von Omega Psi

View im Flash sind die sichtbaren Aspekte... das, was auf der Bühne erscheint. Controller ist die Logik (ausgelagerter AS-Code vereinfacht die Anschauung)

Danke, das hätte ich nicht so treffend formulieren können [vorsicht ironie...]

Zitat von Omega Psi

Nein, das ist Konzeptionell nicht ganz richtig. Der Controller übernimmt auch die interne Umstrukturierung der Daten. Sonst hättest du 2 Modells und 2 Controller.

Ich bin mir da nicht so sicher, ob du hier Recht hast bzw. meine Frage richtig verstanden hast. Nehmen wir einmal an, ich Programmiere ein Gästebuch, das vollständig auf dem Client im Flash Player läuft. Dann habe ich View, Controller und ein Model, das die Daten lokal speichert. Wenn ich jetzt daraus eine Anwendung mit Datanbank-Backend machen will, dann muss ich nur das Model ersetzen. Wenn die Datenbank jetzt auf einem Webserver liegt und ich sie durch PHP abfrage, dann kann das auch nicht viel Unterschied machen; das Model fragt seine Daten halt aus der Datenbank ab bzw. sendet die Änderungen intern auch an die Datenbank. Davon dürften ja View und Controller nichts mitbekommen – sonst hätte das Pattern keinen Sinn.

Zitat von Omega Psi

Captchaprüfung gehört zum Controller.

Wie ich im vorigen Post schon geschrieben habe: Wenn es eine rein lokale Anwendung wäre, dann wäre mir das klar. Ich frage mich nur, wie ich das überhaupt integrieren könnte. Das wäre nämlich das einzige Stück Logik überhaupt serverseitig, ist aber leider nötig; sonst könnte ja jeder das Skript einfach im Webbrowser aufrufen und das Guestbook flooden. Aber auch wenn ich jetzt die Captcha-Prüfung wegmache und bspw. eine Zeitbeschränkung serverseitig einführe, dann muss das Model ja Logik beinhalten, um das abzudecken. Andererseits ist das, was ich hier schreibe, an sich schon ein Widerspruch zu dem, dass das Model einfach durch andere Varianten (z.B. lokal) ersetzbar ist. Vielleicht wäre es also besser, dem Model einfach eine Methode mitzugeben, die zurückliefert, ob gerade ein Eintrag hinzugefügt werden kann. Diese Methode würde bei einem LocalModel zwar immer true zurückzugeben, aber erscheint mir halbwegs passend.
Außerdem stimmt es meines Wissens nach auch nicht, dass das Model überhaupt keine Logik enthalten darf. Siehe z.B. http://www.adobe.com/devnet/flash/ar...ontroller.html. In diesem Beispiel enthält das Model auch Logik – wo sollte sie sonst sein...

Zitat von Omega Psi

Ein neues Fenster ist eine Eigenschaft des Views, kein neuer View. Du verwechselst da was.

Vielleicht habe ich das wirklich verwechselt... Ich habe mir einfach gedacht, wenn ich zum Eintrag erstellen komplett andere Steuerelemente usw. habe, kann ich das Ganze gleich als zweite View auslegen. Aber stimmt, logischer ist es sicher anders. Ein Problem weniger

[Omega Psi]

Zitat von klickverbot

Jaja, das ist mir schon klar. Was ich eigentlich damit meinte: Ich bin mir nicht ganz im Klaren darüber, wie sich die Interaktion mit dem Server in das MVC-Pattern einfügt...

• View: Flash Frontend
• Controller: Actionscript + PHP Logik
• Modell: Interne Datenstrukturen (DB-Backend + Datenstrukturen in Flash)

Du kannst dich ja theoretisch entscheiden, in wieweit du deinen Code auf Client- und Serverseite verlagerst. Eine Komplette Representation auf Clientseite ist genau so denkbar wie eine komplette Logik auf Serverseite. Wichtig ist nur, dass es Schnittstellen für den View gibt, um die Datenanzuzeigen.

Danke, das hätte ich nicht so treffend formulieren können [vorsicht ironie...]

Keine Ursache

Ich bin mir da nicht so sicher, ob du hier Recht hast bzw. meine Frage richtig verstanden hast. Nehmen wir einmal an, ich Programmiere ein Gästebuch, das vollständig auf dem Client im Flash Player läuft. Dann habe ich View, Controller und ein Model, das die Daten lokal speichert. Wenn ich jetzt daraus eine Anwendung mit Datanbank-Backend machen will, dann muss ich nur das Model ersetzen. Wenn die Datenbank jetzt auf einem Webserver liegt und ich sie durch PHP abfrage, dann kann das auch nicht viel Unterschied machen; das Model fragt seine Daten halt aus der Datenbank ab bzw. sendet die Änderungen intern auch an die Datenbank. Davon dürften ja View und Controller nichts mitbekommen – sonst hätte das Pattern keinen Sinn.

Genau so sieht es aus... du ersetzt aber das Modell nicht. Wenn du das Modell, die interne Represenation der Daten änderst, hast du ein Problem. Das Modell wird aus Datenquellen gefüttert, es ist nicht die Datenquelle. Wenn dein Daten eine Text- oder XML-Datei, serialisierte Objekte, distributierte Datenbanken etc sind... ist das für die MVC Pattern egal. Du musst dann nur eine neue Schnittstelle schreiben, um die Daten aus den Datenquellen herauszuholen und in das Modell einfliessen zu lassen. Sonst würde man nach deiner Aussage ja für jedes Speichermedium ein eigenes Modell benötigen.

Wie ich im vorigen Post schon geschrieben habe: Wenn es eine rein lokale Anwendung wäre, dann wäre mir das klar. Ich frage mich nur, wie ich das überhaupt integrieren könnte. Das wäre nämlich das einzige Stück Logik überhaupt serverseitig, ist aber leider nötig; sonst könnte ja jeder das Skript einfach im Webbrowser aufrufen und das Guestbook flooden. Aber auch wenn ich jetzt die Captcha-Prüfung wegmache und bspw. eine Zeitbeschränkung serverseitig einführe, dann muss das Model ja Logik beinhalten, um das abzudecken. Andererseits ist das, was ich hier schreibe, an sich schon ein Widerspruch zu dem, dass das Model einfach durch andere Varianten (z.B. lokal) ersetzbar ist. Vielleicht wäre es also besser, dem Model einfach eine Methode mitzugeben, die zurückliefert, ob gerade ein Eintrag hinzugefügt werden kann. Diese Methode würde bei einem LocalModel zwar immer true zurückzugeben, aber erscheint mir halbwegs passend.
Außerdem stimmt es meines Wissens nach auch nicht, dass das Model überhaupt keine Logik enthalten darf. Siehe z.B. http://www.adobe.com/devnet/flash/ar...ontroller.html. In diesem Beispiel enthält das Model auch Logik – wo sollte sie sonst sein...

Hier ein Auszug aus dem Buch:

• Model: Stores the data and application logic for the interface
• View :Renders the interface (usually to the screen)
• Controller: Responds to user input by modifying the model

Ich habe das Model anders kennengelernt. Aber so richtig eindeutig liest sich mein Beispiel/Definition auch nicht.

Ich würde es so machen:
Der View (Views bei verschiedenen Ausgabemedien) bietet eine visuelle Schnittstelle nach aussen an. Ausserdem beinhaltet der View Schnittstellen zum Controller, damit dieser Änderungen am Modell vornehmen kann. Ausserdem Schnittstellen zum Modell, um es anzuzeigen.

Der Controller umfasst alles, was die interne Verarbeitung von Daten angeht. Schnittstellen zu Views für Inputs und Ausgaben des aktuelisierten Modells, falls dieses nicht zuvor persistent gespeichert wurde.

Das Modell umfasst eine interne Representation von Daten und Schnittstellen zur Ausgabe an den View, sowie Schnittstellen zum Schreiben und Lesen für den Controller. Ausserdem natürlich evtl externe Datenquellen.

Warum? Da es um flexibiltät geht, macht es nicht viel sinn, wenn externe Datenquellen, die Teil des Modells sind, Logik mitzugeben, die die internen Daten verarbeitet. Man will ja so flexible wie möglich mit den Daten sein, und wenn ich eine Datenquelle habe, die mir gleich Java-Objekte liefert, obwohl ich einen C-Controller habe, ist das Geschrei groß. Besser: mein Controller arbeitet die Rohdaten intern auf. So bekommt jeder Controller allgemein gültige Daten und kann die verarbeiten. Ich kann aber nicht leugnen, dass ich stark von der 3 Schicht Architektur beeinflust bin und ich vielleicht deswegen den MVC etwas anders interpretiere.

Die schönste Analogie zu ähnlichen Architekturen sind Webservices... alles kommuniziert über allgemein gültige Protokolle.

Vielleicht habe ich das wirklich verwechselt... Ich habe mir einfach gedacht, wenn ich zum Eintrag erstellen komplett andere Steuerelemente usw. habe, kann ich das Ganze gleich als zweite View auslegen. Aber stimmt, logischer ist es sicher anders. Ein Problem weniger

Ich würde es als ein View betrachten. Weil es nur ein Ausgabeformat ist.

Solche Patterns lassen schon Spiel für Interpretationen... ich orientiere mich sehr stark an der drei Schichten Architektur: GUI, Business Logic, Data Sources...

[klickverbot]

Zitat von Omega Psi

Genau so sieht es aus... du ersetzt aber das Modell nicht. Wenn du das Modell, die interne Represenation der Daten änderst, hast du ein Problem. Das Modell wird aus Datenquellen gefüttert, es ist nicht die Datenquelle. Wenn dein Daten eine Text- oder XML-Datei, serialisierte Objekte, distributierte Datenbanken etc sind... ist das für die MVC Pattern egal. Du musst dann nur eine neue Schnittstelle schreiben, um die Daten aus den Datenquellen herauszuholen und in das Modell einfliessen zu lassen. Sonst würde man nach deiner Aussage ja für jedes Speichermedium ein eigenes Modell benötigen.

Das war ziemlich missverständlich formuliert. Was ich meinte: Wenn ich ein neue Datenquelle habe, dann erstelle ich einfach eine neue Unterklasse von GuestbookModel (das praktisch eine abstrakte Klasse ist) und gebe eine Instanz meinem Controller und meiner View mit auf dem Weg (jaja, vielleicht bin ich ein bisschen zu viel von C++ beeinflusst), denen es egal ist, ob es ein XMLModel oder ein LocalModel oder ein OracleModel ist, hauptsache es leitet sich von GuestbookModel ab.

[Omega Psi]

Genau, entweder du machst es so, oder du baust für den Controller eine Adapterklasse, die diverse Datenquellen ansprechen kann um nur mit einem GuestbookModell zu arbeiten.

In hinblick auf dynamisches Arbeiten hat meine Variante den Vorteil, dass ich ich der Adapterklasse abfragen kann, welche Datenquellen vorhanden sind und die gleich zum laden von Daten verwenden kann. Intern benutze ich dann konsequent nur ein GuestbookModell, dass ich trotzdem zur Laufzeit um Daten aus anderen Datenquellen erweitern kann (was der untenstehende Code nicht demonstriert, aber natürlich wäre es so

class GuestBookModell() {
 
    /** Properties and functions.
          .
          .
          .
          End properties and functions.
      */
 
   /** Adding one entry obtained from the view */
   function addEntry(viewmessages:Array) {
       /** Adding the entry to the datastructures. */
   }
 
   function addEntries(otherguestbookmodell:GuestbookModell):Void {
       /** Add the other entries to this instance of the guestbookmodell. */
   } 

).

Du musst deinem GuestbookController im Code dagegen sagen, welches GuestbookModell er verwenden soll. Was bedeutet, wenn du eine neue Datenquelle benutzt, du eine neue Klasse schreiben muss und diese komplett in dein System einpflegen muss. Dieses ist aber unvernünftig, da die interne Representation der Daten genauso aussieht wie bei den anderen Klassen, Vererbung also gar nicht stattfindet, da du das Modell nicht spezialisierst. Die Daten fliessen nur anders in das System ein.

Konzeptionell wird dein Ansatz spätestens dann unvernünftig, wenn du mit verschiedenen Datenquellen arbeitest. Nehmen wir an, du lädst Artikel von Ebay und Amazon in dein System. Du würdest dann ein AmazonArticleModell und ein EbayArticleModell haben. Zwei verschiedene Objekte, die du theoretisch über Wrapper und TypeCasts irgendwie miteinander verbinden müsstest, sofern du mit ihnen direkt im System arbeiten willst. Ein Umwandlung direkt nach dem Laden in ein Datenformat (Abstrakten Datentypen), erleichtert hingegen das interne arbeiten ungemein.

class DataSourcesConnector {
 
    var dbconnector:DBConnector;
    var txtsource:TXTConnector;
    var xmlsource:XMLConnector;
    var myguestbookmodell:GuestBookModell;
 
    function DataSourcesConnector(_params:Array, _txturl:String, _xmlurl:String) {
        if (_params != null) {
            dbsource = new DBConnector(_params[]);
        } else if (_txturl != null) {
            txtsource = new TXTConnector(_txturl);
        } else if (_xmlurl != null) {
            xmlsource = XMLCOnnector(_xmlurl);
        }
    }
    
    function getGuestBookModell(type:Number): GuestBookModell {
        if (type == 1) {
            return this.getDBSource();
        } else if (type == 2) {
            return this.getTXTSource();
        } else if (type == 3) {
            return this.getXMLSource();
        } else {
            // No valid type specified,
            // return an empty GuestBookModell
            return new GuestBookModell();
        }
    }
 
    function getDBSource():GuestBookModell {
        myguestbookmodell = dbsource.getData();
        return myguestbookmodell;
    }
 
    function getTXTSource():GuestBookModell {
        myguestbookmodell = txtsource.getData();
        return myguestbookmodell;
    }
 
    function getXMLSource():GuestBookModell {
        myguestbookmodell = xmlsource.getData();
        return myguestbookmodell;
    }
}
 
/** Interface for single classes to implement. */
Interface Connector {
 
    /** Retrieving data in a GuestBookModell. */
    function getData():GuestBookModell;
}
 
/** Getting data from the Database. */
class DBConnector implements Connector {
 
    var myguestbookmodell:GuestBookModell;
 
    function DBConnector(_params:Array){
        // 1. Connect to the database
        // 2. Capture the data and make
        //     a GuestBookModell out of it.
    }
 
    function getData():GuestBookModell {
        return myguestbookmodell;
    }
}
 
/** Getting data from a textfile. */
class TXTConnector implements Connector {
 
    var myguestbookmodell:GuestBookModell;
 
    function TXTConnector(_params:Array){
        // 1. Load the textfile.
        // 2. Capture the data and make
        //     a GuestBookModell out of it.
    }
 
    function getData():GuestBookModell {
        return myguestbookmodell;
    }
}
 
/** Getting data from a textfile. */
class XMLConnector implements Connector {
 
    var myguestbookmodell:GuestBookModell;
 
    function XMLConnector(_url:String){
        // 1. Load the XML
        // 2. Capture the data and make
        //     a GuestBookModell out of it.        
    }
 
    function getData():GuestBookModell {
        return myguestbookmodell;
    }
} 

So würde ich es machen... das ist halt nur eine Skizze, um meine Backend-Communication zu skizzieren.

[bokel]

Interessanter Thread.
Um das ganze etwas anschaulicher zu machen, habe ich mal ein sehr einfaches Gästebuch nach dem MVC Prinzip umgesetzt.

www.bokelberg.de/download/guestbook_01.zip

mfg. r

[klickverbot]

Zitat von Bockel

Interessanter Thread.

Meinst du das ernst?

Zitat von Omega Psi

Konzeptionell wird dein Ansatz spätestens dann unvernünftig, wenn du mit verschiedenen Datenquellen arbeitest. Nehmen wir an, du lädst Artikel von Ebay und Amazon in dein System. Du würdest dann ein AmazonArticleModell und ein EbayArticleModell haben. Zwei verschiedene Objekte, die du theoretisch über Wrapper und TypeCasts irgendwie miteinander verbinden müsstest, sofern du mit ihnen direkt im System arbeiten willst.

Ich glaube, dass ich mit meinem Absatz gar nicht so viel komplizierter fahre. Ich kann zwar nicht zwei Quellen gleichzeitig nutzen, aber da würde das MVC-Pattern wohl ohnehin ein kombinierendes Model erfordern (sofern die Daten in der gleichen View und mit Hilfe des gleichen Controllers verarbeitet werden).

Hier habe ich das einmal skizzenhaft dargestellt (ja, ich weiß, es gibt kein abstract usw.)

/**
 * Controller.
 */
class ItemSearchController {
    public function getModel() :ItemSearchModel {
        return m_model;
    }
    public function setModel( model :ItemSearchModel ) :Void {
        m_model = model;
        m_model.update();
    }
    private var m_model :ItemSearchModel;
}
 
/**
 * Model.
 */
abstract class ItemSearchModel {
    public abstract function search( query :String );
    
    public function addView( view :ItemSearchView ) {
        [...]
    }
    public function removeView( view :ItemSearchView ) {
        [...]
    }   
    public function update() :Void {
        [...]
    }
}
 
class EbaySearchModel extends ItemSearchModel {
    public function search( query :String ) :Boolean {
        [..]
    }
}
 
class AmazonSearchModel extends ItemSearchModel {
    public function search( query :String ) :Boolean {
        [..]
    }
}
 
/**
 * Application
 */
class ItemSearchModel {
    public function ItemSearch( container :MovieClip ) {
        m_container = container;
    }
    
    public function run() :Void {
        var view :ItemSearchView = new ItemSearchView( m_container );
        var controller :ItemSearchController = new ItemSearchController();
        var ebayModel :ItemSearchModel = new EbaySearchModel();
        
        view.setController( controller );
        controller.setView( view );
        controller.setModel( ebayModel );
        ebayModel.addView( view );
        
        ebayModel.update();
        
        // Wenn ich jetzt lieber amazon nutzen würde, müsste ich ja nur das machen:
        ebayModel.removeView( view );
        var amazonModel :ItemSearchModel = new AmazonSearchModel();
        
        controller.setModel( amazonModel );
        amazonModel.addView( view );
        amzoneModel.update();
    }
    
    public static function main( container :MovieClip ) {
        var instance :ItemSearch = new ItemSearch( container );
        container.run();
    }
    
    private var m_container :MovieClip;
} 

Nochmal zurück zu den Captchas: Wie würde ich sie eurer Meinung nach am besten integrieren? Wenn das Captcha jetzt ein reines clientside-Feature wäre, dann wäre der Fall klar (Überprüfung in den Controller, da das Captcha nichts mit den Daten an sich zu tun hat). Aber da ich jetzt einmal angenommen habe, dass diese Überprüfung serverseitig implementiert ist und die Flash-Anwendung bzw. jeder andere Client erst dann schreibend auf die Datenbank zugreifen kann, wenn das Captcha gelöst wurde, habe ich ein Problem. Natürlich müsste ich mir das bei einem konkreten Projekt noch genauer überprüfen, aber mir fällt im Moment keine gute andere Möglichkeit ein, Spam zu verhindern. Nur das .swf-File auf die Datenbank zugreifen zu lassen ist ja leider nicht so einfach möglich, da man 1. einfach den HTTP-Verkehr abhören kann und 2. eine Überprüfung im swf per se unsicher ist (Stichwort dekompilierbar, manipulierbar...)

Eine Frage zu dem Entwurf von bockel: Du speicherst ja den Status (hinzufügen, anzeigen) der View im Model. Wenn ich jetzt eine View implementieren würde, bei der beides parallel möglich wäre (zum Beispiel ein zweigeteiltes Fenster), dann hätte ich ein Problem. Es gehört ja nicht wirklich zu der "Logik" eines Gästebuchs, dass es zwei verschiedene Modi (Hinzufügen und Anzeigen) hat und hat demnach meiner Meinung nach nicht wirklich was im Model zu suchen.

Und noch was: Nehmen wir an, meine Gästebuchapplikation hätte mehrere Gästebücher, aus denen der Benutzer auswählen kann. Dann brauche ich ja eine eigene Navigation dafür. Eigentlich spräche nichts dagegen, dass als eine eigene View neben der Anzeige zu implementieren, oder? Der zugehörige Controller würde dann Model.setActiveBook() aufrufen, worauf das Model unter anderem die andere View benachrichtigen würde...

1 Portion Erleuchtung bitte^^

[Omega Psi]

Schick schick das Gästebuch.

Ehrlich gesagt ist das das erste mal, dass ich Software nach MVC modelliert sehe.

Sieht schick aus. Ich preferiere aber doch eher die 3, bzw mehr als 3 Schicht Architektur. Eine klare Trennung von GUI, Logik und Datenhaltung ist für mich der klare Vorteil. Da MVC anscheinend, je nach Beispiel, mal mehr mal weniger Logik für das Modell vorsieht, halte ich mich da lieber an Schnittstellen und Komponenten...

Aber es ist ja nichts schlechtes!

[Omega Psi]

Hm, aber da frage ich dich einfach mal so direkt, wieviel Sinn eine solche Archtektur macht.

Du kannst entweder ein Ebay- oder ein AmazonSearchmodel starten. Also, da würde ich sagen, zurück ans Reisbrett. Ich denke, auf sowas ziehlt eine MVC-Architektur nicht ab.

Du müsstest dein Modell dann so aufbauen, dass es sowohl mit Amazon als auch Ebay arbeiten kann. Der Controller würde dann die Artikel entgegennehmen.

Wenn ich es (deinen Code) nun richtig interpretiere, musst du ja deine Application jedesmal neu starten, wenn du ein anderes Model benutzen willst. Das wäre ja so, als wenn man deinen Mediaplayer jedesmal runterfahren muss, nur weil man dieser einen anderen Codec braucht...

[Omega Psi]

Nochmal zurück zu den Captchas: Wie würde ich sie eurer Meinung nach am besten integrieren? Wenn das Captcha jetzt ein reines clientside-Feature wäre, dann wäre der Fall klar (Überprüfung in den Controller, da das Captcha nichts mit den Daten an sich zu tun hat). Aber da ich jetzt einmal angenommen habe, dass diese Überprüfung serverseitig implementiert ist und die Flash-Anwendung bzw. jeder andere Client erst dann schreibend auf die Datenbank zugreifen kann, wenn das Captcha gelöst wurde, habe ich ein Problem. Natürlich müsste ich mir das bei einem konkreten Projekt noch genauer überprüfen, aber mir fällt im Moment keine gute andere Möglichkeit ein, Spam zu verhindern. Nur das .swf-File auf die Datenbank zugreifen zu lassen ist ja leider nicht so einfach möglich, da man 1. einfach den HTTP-Verkehr abhören kann und 2. eine Überprüfung im swf per se unsicher ist (Stichwort dekompilierbar, manipulierbar...)

Kannst du das nicht eine POST-Anfrage stellen und dir eine Erlaubnis von Server holen, die Nachricht zu speichern?

Eine Frage zu dem Entwurf von bockel: Du speicherst ja den Status (hinzufügen, anzeigen) der View im Model. Wenn ich jetzt eine View implementieren würde, bei der beides parallel möglich wäre (zum Beispiel ein zweigeteiltes Fenster), dann hätte ich ein Problem. Es gehört ja nicht wirklich zu der "Logik" eines Gästebuchs, dass es zwei verschiedene Modi (Hinzufügen und Anzeigen) hat und hat demnach meiner Meinung nach nicht wirklich was im Model zu suchen.

Und noch was: Nehmen wir an, meine Gästebuchapplikation hätte mehrere Gästebücher, aus denen der Benutzer auswählen kann. Dann brauche ich ja eine eigene Navigation dafür. Eigentlich spräche nichts dagegen, dass als eine eigene View neben der Anzeige zu implementieren, oder? Der zugehörige Controller würde dann Model.setActiveBook() aufrufen, worauf das Model unter anderem die andere View benachrichtigen würde...

Und wieder denke ich, dass es konzeptionell nicht richtig sein kann. Wenn du eine neue View konzipierst, brauchst du auch einen neuen Controller... und eigentlich auch ein neues Modell.

Ich glaube du denkst bei einer View an ein Fenster, das erzeugt wird. Das kann nicht ganz richtig sein, da der Controller auf jedes Fenster reagieren muss... Deine herangehensweise lässt einen Schluss zu ein System zu, dass man soviele Views basteln kann, wie man lustig ist. Diese brauchen aber aber auch die entsprechenden Controller. Dem Controller soll es aber egal sein, was für ein Fenster er abhört, es geht nur um die Schnittstellen.

Eine Applikation in 3 Komponenten aufzuteilen, macht sonst keinen Sinn. Betrachtest du alles was sichtbar und anklickbar ist als eine eigenständige View hättest du ein M(V * n)C... von den Controllern, die du anständigerweise mit implementieren müsstest ganz zu schweigen.

Es handelt sich nur um ein Kozept, eine Architektur... nicht um ein Rezept, wie eine Applikation im Endeffekt aufgebaut sein muss (Anzahl der Fenster, Controller etc).

[bokel]

Wg Captchas:
Captchas würde ich so implementieren, dass die Antwort des Users an den Server geschickt wird und dann von dort ein Token zurückgeliefert wird, das weiterhin zum Schreiben gebraucht wird.

Wg. des ViewStates im Model:
Das Model kann viele verschiedene Aspekte haben. Es kommt immer drauf an, was die Views halt so brauchen. Ein View, der beides gleichzeitig anzeigt, könnte die ViewStates ja einfach ignorieren. Alles was State ist, gehört ins Model. In groesseren Applikationen könnte man das Model sicher weiter unterteilen.

Wg. mehreren Gästebüchern:
Genauso kannst du das machen. Das sollte ohne weiteres klappen.

Wg. Mehrschichtarchitektur:
Das Model ist ja jetzt sehr primitiv aufgebaut. Darunter kannst du dir noch beliebige Schichten vorstellen. Normalerweise benutze ich Flex/Flash als Client in J2EE Applikationen. Dabei ist praktisch das, was Struts und Konsorten als Client abbilden in den Flashclient gewandert. Darunter kannst du noch Schichten anhäufen ohne Ende. Jeder Kunde denkt darüber anders.

mfg. r

[MaticPel]

Wieso willst du denn die Logik in den Controller packen?
Ich fand anfangs den Begriff Model auch immer total verwirrend, da man damit assoziert, dass er nur ein Datenmodell oder ähnliches darstellt. Und unter Controller stellt man sich den vor, der "das Sagen" hat. Aber eigentlich kontrolliert ja der Kontroller nur das was im View passiert.

View
Repräsentation des Models. Erhält den Zustand und die Daten die er benötigt vom Model

Controller
Nimmt die Eingabe des Benutzers an und stellt fest, was sie für das Modell bedeutet. Er trennt die Steuerungslogik vom View und entkoppelt den View vom Model. Der Controller implementiert Verhalten für den View, aber nie Anwendungslogik. Er ist der kluge Kopf, der die Aktionen vom View in Aktionen auf dm Model übersetzt. Das Model nimmt diese Aktionen an und implementiert die Anwendungslogik, die entscheidet, welche Reaktion auf diese Aktion angebracht ist. Der Controller muss vielleicht ein bisschen arbeiten, um zu entscheiden, welche Methodenaufrufe auf dem Model erforderlich sind, aber das kann man nicht als Anwendungslogik betrachten. Die Antwendungslogik ist der Code, der die Daten verwaltet und manipuliert und dieser kommt im Model vor.

Model
Enthält die gesamte Daten-, Zustands- und Anwendungslogik.
Es kann Benachrichtigungen an den Beobachter senden.

Also ich pack alles ins Model bzw. in die Modelebene. Und der Controller ist nur da um auf Interaktion zu reagieren und wenn es einfache Interaktionen sind, die für das Model nicht entscheidend sind, wie z.B. das leeren eines Textfeldes, dann macht er das und wenn es Aktionen sind, die am Model etwa s ändern, dann leitet er das an das Model weiter und bereitet das vielleicht vorher noch richtig aus, was ja dann sowas wäre wie "Text aus dem Textfeld auslesen und an die Model-Funktion reichen.