MVC verständisfrage

[StayFrosty]

hallo!
ich versuche mich gerade mit mvc auseinanderzusetzen. ich dachte ich hätte das prinzip verstanden. die simplen beispiele versteht man ja immer ziemlich schnell. möchte man es dann aber auf ein reales projekt umwälzen seh ich nur noch fragezeichen.

um es auf den punkt zu bringen. auch hier wieder extrem vereinfacht: sagen wir mal ich hab 10 oder besser 30 verschiedene shapes die erstellt werden. diese haben alle verschiedene eigeschaften: vielleicht eine überschrift, eine farbe und eine boolesche variable. laut mvc prinzip sollen ja all diese eigenschaften in den model rein, weil es hier "daten" sind - richtig? nur schon hier verstehe ich es nicht ganz wie ich all diese werte nun managen soll wenn ich auf diese später zurückgreifen will. packt man diese in ein array oder erstellt man irgendwie Sub-Models? oder wie? bahnhof....

besten dank für jegliche art von hilfe

liebe grüsse

[shredding]

Wenn die Eigenschaften tatsächlich aus einer Datenquelle kommen (z.B. einer Datenbank oder einer XML), dann würde das Model beispielsweise das einlesen und parsen der XML übernehmen und daraus klassen instanziieren und in diesen die Eigenschaften setzen.

Du hättest also eine Klasse Shapes und 10-30 Instanzen davon. Die haben prinzipiell nichts mit dem Model zu tun, sondern das Model würde nur die Daten dafür liefern.

Die Frage die du dir stellen musst ist: Wie tausche ich möglichst wenig aus, wenn sich die Datenquelle ändert?

Wenn das Model das einlesen, parsen und instanziieren auf Basis dieser Daten übernimmt, dann bräuchtest du es nur durch ein anderes Model austauschen, dass vielleicht eine Verbindung zur Datenbank statt zur XML herstellt.

Man kann es auch noch weiter Treiben und eine Klasse für das Model schreiben, dass verschiedene Datenquellen wie ein Plugin hinzuzieht und die das instanziieren übernimmt ...

Das ist immer so eine Sache in der Softwarearchitektur, wie komplex man denn die Komplexität reduzieren möchte.

[StayFrosty]

danke für den reply shredding

hmm...
verstehe ich das richtig, dass nicht alles was mit "daten" zu tun hat auch zwingend in den model rein muss?

sagen wir mal wieder mit diesen shapes: alle habe einen parameter "on" der einfach standardmässig bei generierung erzeugt wird. wenn man draufklickt, schaltet der auf "off"...ist dieser parameter nun auf dem objekt oder wird dieser im model ausgelagert? habe ich dich missverstanden?

besten dank

[Omega Psi]

Naja, alles was du als Zustand definierst, sollte im Modell liegen, damit du überhaupt die Möglichkeit hast, eine Form von Persistenz zu ermöglichen. Wenn es nur das Verhalten der View definiert, muss das nicht ins Modell.

[shredding]

Zitat von StayFrosty

sagen wir mal wieder mit diesen shapes: alle habe einen parameter "on" der einfach standardmässig bei generierung erzeugt wird. wenn man draufklickt, schaltet der auf "off"...ist dieser parameter nun auf dem objekt oder wird dieser im model ausgelagert?

Das würde ich in den View packen. Wenn der Zustand gespeichert wird, würde ich diese Information dann (zB wie Observer Pattern) an das Model weiterreichen.

[StayFrosty]

danke euch beiden. ich muss da leider nachhaken

Naja, alles was du als Zustand definierst, sollte im Modell liegen, damit du überhaupt die Möglichkeit hast, eine Form von Persistenz zu ermöglichen. Wenn es nur das Verhalten der View definiert, muss das nicht ins Modell.

...sagen wir mal es definiert nicht nur das verhalten der view..wie sieht das in der praxis aus? ohne mvc habe ich objektspezifische zustände direkt im objekt geändert z.b. mit einer setter methode. packt man jetzt sämtliche zustände jetzt in irgendwelche arrays? *sich duck* sorry für die verwirrung. irgendwie blick ich da nicht durch...vielleicht habt ihr ja gute beispiele, die ich mir anschauen kann.

[Omega Psi]

Entweder oder.

Eine Eigenschaft beschreibt das Verhalten, bzw. den Zustand der View oder es ist ein Teil des Zustands der Anwendung. Wenn ein Button nun in Abhängigkeit den Zustands des Modells enabled oder disabled sein soll, muss man das entsprechend abbilden.

[shredding]

<unbezahlteWerbung>
Dein gesamtes Verständis von MVC, Design Patterns, Programmierung, der Welt und wie Frauen ticken wird sich grundlegend erhellen, wenn du dieses Buch liest:

Entwurfsmuster von Kopf bis Fuß: Amazon.de: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Bücher
</unbezahlteWerbung>

Mal etwas unabstrakt formuliert und so wie ich die Sache sehe und nicht wie sie unbedingt richtig ist - es gibt abweichende Ansichten zu dem Thema:

MVC ist in meinen Augen kein Design Pattern, sondern eine Komposition aus verschiedenen Design Patterns (weshalb es klug ist, obiges Buch zu lesen).

Ziel dieser Komposition ist es, Parts deiner Anwendung zu entkoppeln:

Wenn du heute eine App baust, ist es wahrscheinlich, dass du sie mal für eine Webseite, mal für Android, iPad etc baust.

Es kann auch sein, dass du eine Online-Variante mit Datenbankanbindung bereit stellst und eine Variante die auch offline funktioniert und daher nur ab und zu eine XML austauscht.

D.h. du hast zwei Enden, die möglichst keine Details voneinander zu wissen brauchen: Die Views sollen nicht wissen ob die Daten gerade von einer Datenbank kommen oder von einer XML, genausowenig wie es das Model interessieren soll, ob die Daten später auf dem iPad oder dem Computer angezeigt werden, oder einem Gerät, dass zum Zeitpunkt der Modelprogrammierung noch gar nicht erfunden war.

Wenn du eine Setter Methode hast, ist das doch schon der erste Schritt zum entkoppeln. Die Setter Methode sollte dann eben Daten so geliefert bekommen, dass die Quelle egal ist (d.h. das Model sollte die Daten nach einer bestimmten Art aufbereiten, die immer gleich ist, egal ob die Daten aus einer DB oder sonstwo herkommen).

Stell dir vor du hast ein Textfeld, wo ein Blogartikel aus einem RSS Feed gezeigt werden soll. Das Textfeld gehört zum View.

Du erstellst eine Klasse "Article", die hat Setter für alles mögliche (Titel, Description) und auch Getter. Sie ist eine Art Übersetzer: Das Model übergibt die Daten, so wie es in dem Setter definiert ist.

Die Viewklasse (die auch das Textfeld verwaltet) holt sich die Daten aus dem Getter heraus und knallt sie in das Textfeld rein.

Jetzt sind View und Model entkoppelt und wir können uns darüber streiten ob die Article Klasse jetzt zum Controller gehört oder zum Model (ich würde sagen zum Model, weil sie die Schnittstelle von den Daten zum View repräsentiert).

So ähnlich wäre es auch bei deinen Shapes.

In der Praxis kommunizieren die einzelnen Komponenten meist etwas komplexer mit Patterns wie dem Observer Pattern oder via Dependency Objection, die die Entkopplung noch weiter treiben - was viele Vorteile mit sich bringt. Es gibt eine Menge Frameworks, die eine Referenzimplementierung von MVC bieten und es gibt Grabenkriege darüber, welches die beste ist. Meiner Meinung nach ist PureMVC übrigens die Beste und ich habe hier eine Einführung dazu geschrieben wo ich ein bisschen was über den Aufbau des MVC Modells dort schreibe:

http://www.as3dp.com/2011/06/28/pure...istian-peters/

[malthoff]

Deine Frage zielt auf die Datenstruktur im Model - weniger um den Sinn des selben, richtig? Also *wie* werden die Daten gespeichert und nicht Warum. Das Warum wurde an einigen Beispielen in den Antworten zuvor beantwortet.

Dazu noch mal genereller: Bei der objektorientierten Programmierung versuchst Du Daten und die darauf arbeitenden Funktionen in einem Objekt zu bündeln. Dieses Objekt sollte möglichst (nicht immer möglich) nur einer Aufgabe nachkommen. Im Falle des Models könnte man sagen, dass die Aufgabe ist den Zustand der Anwendung zu speichern und eventuell Änderungen daran vorzunehmen. Vorteil: Durch die Bündelung in einem Objekt (Model) können alle anderen Objekt durch ein definiertes Interface (öffentliche Methoden der Model Klasse) auf die Daten zugreifen oder sie beeinflussen. Der Zustand ist also nicht wild über die Anwendung verteilt, sondern haben Ihren zentralen Platz.

Jetzt zum Wie:
Es gibt selbst verständlich unendliche Möglichkeiten, wie Du Deine Daten im Model speichern kannst und je nach Komplexität der Anwendung kann auch das Model zunehmend komplexer aussehen. In 90% der Fälle kannst Du bereits mit wenigen und flachen Datenstrukturen sehr viel abbilden.

Dein Ansatz mit den Arrays war völlig legitim und stellt eine sehr einfache Art dar, Daten zu speichern. Dein Hauptaugenmerk sollte darauf liegen, dass es für Dich nicht zu komplex wird und das bedeutet auch, dass die Struktur im Model nicht unnötig komplex werden muss. Denk daran, dass Du auch die Methoden schreiben musst, die auf den Datenstrukturen arbeiten. Je aufwendiger die Struktur, desto aufwendiger die Methoden.

Um auf Dein Beispiel zu kommen: Du sprichst von Shapes mit Farbe, Überschrift und einen Flag. Es ist sehr weit verbreitet Daten in einem Model in sogenannten Value Objects zu speichern. Das sind reine Datenhaltungsklassen mit keiner Funktion, außer das sie Daten speichern und den Daten durch den Klassennamen eine Bedeutung geben -> Übersicht für den Programmierer.

Dir steht völlig frei, wie Du die Klasse nennst, aber ich nenne sie jetzt mal ShapeVO. Das könnte so aussehen:

class ShapeVO {

     public var color:Number;
     public var active:Boolean = false;
     public var headline:String = 'not set yet';

     public function ShapeVO() {}
}

Ob Du die Felder, wie Color etc., per Getter und Setter vor direktem Zugriff schützt sei Dir überlassen, bei reinen Value Objects spare ich mir den Aufwand und den Code.

Ein Beispiel Szenario könnte jetzt so aussehen, dass Du die Werte Deiner 30 Shapes per XML lädst, das Model parsed die Daten und erzeugt für jeden Shape Node in XML ein ShapeVO Objekt und übergibt die Daten im Konstruktor. (natürlich kannst Du sie auch über setter setzen, aber das sei hier mal Nebensache).

Diese Shape Value Objects speicherst Du ganz einfach in einem Array im Model (allShapes:Array). Dann kannst Du noch Model Methoden schreiben, die Dir bspw. alle blauen Shapes raus gibt. So eine Funktion wäre dann eine der oben erwähnten Interfacemethoden des Models.

Beispiel:

function getAllShapesByColor(wantedColor:Number):Array {
     var foundShapes:Array = [];
     for (var i:int = 0; i < allShapes.length; i++) {
             var shape:ShapeVO = ShapeVO(allShapes[i]);
             if (shape.color == wantedColor) foundShapes.push(shape); 
     }
     
     return foundShapes;
}

Irgendeine andere Klasse, die Zugriff auf das Model hat, kann nun blaue Shapes anfordern:

model.getAllShapesByColor(0x0000ff);

Du siehst, das Speichern im Model kann so einfach sein, wie das Speichern von Objekten in einem Array.

Ein komplexeres Beispiel könnte das Model eines Computerspiels sein. Stell Dir ein Spiel wie Monkey Island vor - im Model würde gespeichert, in welchem Screen, an welcher Stelle im Spiel sich der Spieler befindet und wohin der gehen kann. So eine Abhängigkeit lässt sich wahrscheinlich nicht mit einem einfachen Array lösen.

[StayFrosty]

hallo zusammen

ich danke allen für die ausführlichen erklärungen!

@shredding
ich dachte diese buch-serien sind mehr für java-anwender. natürlich ist es mehr oder weniger "das selbe" wahrscheinlich - aber schon nur wegen den abstrakten klassen gibt es in as3 unterschiede. "aber alleine den a*** abwischen kannst du schon noch oder?" ...schon klar was du denkst . ich hab erst vor ein paar monaten as3 gelernt, dann oop-basics und bin jetzt dran mit design patterns und mein kopf ist schon ziemlich voll . ist für mich als designer alles neuland und nicht so einfach und bin darum froh, wenn schon alles "richtig" geschrieben ist. meine gehirnprozesse müssen sich glaube ich zuerst dran gewöhnen

@malthoff
irgendwie verstehe ich deine posts immer am besten. sollte überhaupt nicht beleidigend für die anderen poster sein hier- es ist halt so, dass man je nach formulierung manche besser versteht als andere. ich danke dir! genau das "wie" habe ich gebraucht. man erstellt in meinem beispiel für jedes objektlein (also hier shapes) sein zugehöriges value object (was ja eigentlich ein teil des models ist?). diese objekte fügt man dann im model z.b. in einem array damit man sie später wieder aufrufen kann. wie sieht aber die verbindung aus? wie weiss ich, welches shape zu welchem value object gehört? könnte man dies mit einer "id" lösen oder wie würdest du das machen?

besten dank und grüsse

[malthoff]

Die Value Objects gehören ins Model, ja. Sie werden aber auch an anderen Stellen in der Anwendung verwendet. Wie weit sich ein Value Objects in den Tiefen deiner Anwendung verirrt liegt wieder bei Dir oder besser Deiner Entscheidung, wie genau du es mit der Trennung von Verantwortlichkeiten nimmst.

Wir hatten das Thema schon, dass eine Klasse sich, wenn man es ganz genau nimmt, nur um seine eigenen Sachen kümmern soll. In anderen Worten: Es soll vom Gesamtsystem so wenig wie möglich, aber soviel wie nötig wissen. Das führt zu zwei möglichen Ausprägungen. Entweder man übergibt der Shape View Klasse das gesamte Objekt:

PHP-Code:

class ShapeView{

     public function ShapeView(vo:ShapeVO) {
          // code using the vo attributes to draw the shape
     }
} 


Oder man sagt sich: " Was hat es denn die View zu interessieren, dass außerhalb von ihr ein System existiert, welches Daten in komischen ValueObjects speichert? Das einzige was die View wirklich braucht sind doch die drei Werte!" Was zu folgendem Ergebnis führt:

PHP-Code:

class ShapeView{

     public function ShapeView(color:Number, headlineText:String, active:Boolean) {
          // code directly using the given values
     }
} 


Die Fragestellung ist einleuchtend und eine Meinung schnell, vielleicht voreilig gebildet: "Richtig!!! Die View interessiert nichts anderes, als die Werte die es wirklich braucht. Außerdem kann ich so viel besser "mal eben" eine Instanz von ShapeView erzeugen, da die Konstruktorargumente alles primitive Datentypen sind!"

Das ist aber wieder ein TradeOff. Stell Dir vor, es wären nicht drei, sondern 10 Attribute, die notwendig sind. Dann macht es keinen Sinn mehr, 10 Werte in den Konstrutor zu schießen - wer weiß, wie weit diese Werte innerhalb der View weitergereicht werden müssen...

Es ist immer ein reines Abwägen von Übersichtlichkeit, Kapselung von Daten an der richtigen Stelle, und Struktur/Fluss innerhalb der Gesamtanwendung ("Wie sprechen einzelne Objekte mit einander und wie sieht der Datenaustausch aus").

Falls Du Dich fragst, wer im Falle 2 für das Auspacken der Daten aus dem ValueObject zuständig ist, stell Dir ein zwischengeschaltetes Objekt vor, vielleicht Factory genannt, dessen einzige Aufgabe es ist, Objekte eines speziellen Types zu bauen, also Klassen zu instanziieren um sie dann fertig an jemand anderen zu übergeben. Diese Factory darf vielleicht schon eher von "ValueObjects" wissen, weil sie Bestandteil des Systems ist - von dem Views eher entkoppelt sein sollten.

Die Verbindung zwischen den Model Daten und den Repräsentanten auf View Ebene ist ein Thema für sich. Ich löse das auch meist über IDs. Schau Dir dazu mal die Dictonary Klasse in AS3 an. Mit Hilfe dieser Datenstruktur kannst Du ein "echtes Object", in dem Fall ein ValueObject mit einem anderen Objekt verbinden, hier vielleicht einer ID:

PHP-Code:


var id:int = 23;
var vo:ValueObject = new ValueObject(//blabla);
var dict:Dictonary = new Dictionary(true);

dict[vo] = id; 


später im code kannst Du über die Referenz des ValueObjects die ID ganz einfacher zurück bekommen:

PHP-Code:

 var id = dict[vo] 


[Omega Psi]

Ich sehe das nicht so. Wenn man nicht an einem Framework arbeitet, dem das Datenmodell prinzipiell egal ist, können (und sollten) Views genauso die Schnittstellen kennen, wie es Services tun. Alles andere ist nicht wirklich produktiv. Eine Anwendung sollte skalieren, nicht super generisch sein.

Ähnlich betrachte ich den Zugriff via id, auf eine id wie eben illustriert. Wieso hat das VO nicht einfach eine Eigenschaft id? Zugriffe auf eine Instanz via id sollte im Idealfall über Collection erfolgen und die Referenzen/Identitäten der Instanzen sind nicht nur schneller, sondern auch sicherer.

[malthoff]

Nachvollziehbar. Das ein ValueObject eine ID haben kann ist natürlich auch möglich und ist sinnvoll.

[StayFrosty]

@omega
sorry. verstehe ich nicht mit der id. collection was?

[Nico B.]

Er meint, dass Dein Valueobject selbst eine Eigenschaft "id" haben sollte.

var valueObject = new ValueObject();
valueObject.id = 23;
valueObject.name = "Peter"; 

usw...