turk porno porno escort rokettube
Ergebnis 1 bis 20 von 20

Thema: [MVC] Unklarheiten zum "Model"-Komponent

  1. #1
    Benutzer
    Registriert seit
    08.07.2007
    Beiträge
    32
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard [MVC] Unklarheiten zum "Model"-Komponent

    Hallo,

    immer wenn ich etwas vom MVC-Pattern lese, glaube ich zwar alles zu verstehen, aber gleichzeitig weiß ich nie genau, wie ich mit diesem Prinzip ein Programm schreiben soll. Eigentlich bereitet mir nur der "Model"-Part des Prinzips Kopfzerbrechen, da sich die vielen Texte die ich dazu las teilweise widersprachen oder sich einfach zu abstrakt/zu simpel hielten, als dass ich mit ihnen bei realen Problemstellungen etwas anfangen konnte.

    Vielleicht liegt diese "Schwammigkeit" daran, dass jeder das MCV-Pattern anders umsetzt (?) und es deswegen einfach keine generelle Definition gibt - dennoch hätte ich gerne ein paar konkrete Antworten auf meine Fragen. Schließlich sollen Design-Patterns ja Probleme in Best-Practise-Manier lösen und einem keine neuen "aufzwingen".


    Was genau ist das "Model" überhaupt, oder was sollte es in meinem Programm sein?

    Generell ist mir unklar, was das Model nun überhaupt darstellt. Bei manchen Beispielen ist das Model ein Objekt, welches eine Reihe von zusammenhängenden Informationen enthält (z.B. Kreditkarte mit: Nr, Eigner, Ablaufsdatum, etc.) und bei anderen verwalten mit einem Model gleich eine Reihe von Objekten (mit Methoden wie "getCreditcardsByOwner(..)").

    Ich halte beide Ansätze für recht sinnvoll, da #1 nach meinem Verständnis der Theorie ja wirklich ein "Model(l)" darstellt und #2 die Logik gut (?) aus dem Controller auslagern würde.

    Wie sollte man das aber nun in der Realität machen?
    1. Ansatz 1 & 2 in einem Model kombinieren, was gleichzeitig eines, aber auch mehrere Objekte ansprechen kann?
    2. Ansatz 1 & 2 zu zwei Modellen machen, die untereinander agieren können? Bsp.: Model X liefert bei einem Aufruf von getElementsByAuthor(..) eine Liste mit Modellen Y zurück.
    3. Ansatz 1 & 2 zu zwei Modellen machen, die vollkommen autark voneinander agieren können? Bsp.: Model X liefert beim Aufruf von getElementsByAuthor(..) Arrays mit Strings für die Weiterverarbeitung und Darstellung im Controller bzw. View. Model Y hat damit überhaupt nichts zu tun und kann vom Controller angesprochen werden, wenn der Benutzer z.B. ein Element ändert.
    4. Nur einen der beiden Ansätze benutzen und den Rest im Controller auslagern?
    5. Je nach Situation / anderes..


    Punkt 3 erscheint mir am bequemsten, da er relativ ordentlich ist und dabei keine riesen Umstände wie z.B. Pkt 2 macht. Welchen Ansatz benutzt ihr weswegen? Oder wie macht ihr es, ohne das Model so konkret zu gestalten, dass man es nicht wiederbenutzen kann?

    Anschlussfrage: Sollte man bei Ansatz 2 auch Veränderungen an mehreren Objekten durchführen können, oder sollte dies besser Aufgabe von Ansatz 1 sein?

    Grüße, Florian


    PS: Normalerweise schreibe ich nicht so viel Text..

    PPS: ..aber wenn ich es tue, dann klären sich mir viele Fragen von selbst, bzw. erscheinen unsinnig. Deswegen ist die finale Frage vielleicht etwas konkreter, als man nach der Einleitung erwartet hätte. Trotzdem wollte ich meinen Gedankengang nicht komplett löschen.

  2. #2
    Erfahrener Benutzer Avatar von ChristianFischer
    Registriert seit
    26.04.2007
    Beiträge
    730
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Also ich versuch jetzt mal keinen Quatsch zu schreiben wenns einer besser weiß bitte verbessern.

    Ein Model ist der Part in deiner Anwendung die sich um die ganzen Daten Sachen kümmert. Daten holen (mit Filter) ,löschen, ändern.

    Beim ZF kann ein Model "n" "Objekte" darstellen.

    Wenn du dem Model sagst (angenommen es nutzt eine DB) fetchAll. Gibt es dir die Daten aus der Datenbank zurück und du kannst über alle Einträge iterieren.

    Die ominöse Funktion
    getCreditcardsByOwner(..)
    Sieht mir so aus als ob du da ein Beispiel von Relationalem zend DB Zeugs gesehen hast.
    http://framework.zend.com/manual/en/...tionships.html

    Das Ding ist im ZF nämlich eine "Magic" Method und gibt dir ein Abhäniges Rowset zurück.


    Kurz und knapp ist ein Model eigentlich nur die Schnittstelle zu deinen Daten.

  3. #3
    Moderator Avatar von Bleistift
    Registriert seit
    14.12.2006
    Ort
    Zürich (Schweiz)
    Beiträge
    1.580
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Zitat Zitat von ChristianFischer Beitrag anzeigen
    Die ominöse Funktion
    getCreditcardsByOwner(..)
    Sieht mir so aus als ob du da ein Beispiel von Relationalem zend DB Zeugs gesehen hast.
    http://framework.zend.com/manual/en/...tionships.html
    Ich finde dazu leider nichts auf der verlinkten Seite. Auf was genau wolltest du verweisen?
    Moderator
    Kein ZF-Support via Foren-PN

  4. #4
    Erfahrener Benutzer Avatar von ChristianFischer
    Registriert seit
    26.04.2007
    Beiträge
    730
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Example 9.121. Fetching a Dependent Rowset By a Specific Rule <-- das im besonderen

    Aber eigentlich ist das ganze Kapitel relevant um Beziehung zwischen DB´s zuverstehen.
    (du kannst es dir sparen wenn du nicht myisam nimmst, denn dann kannst du das alles direkt in deiner db machen, steht auch dauernd in dem Text da ^^)
    Geändert von ChristianFischer (10.07.2007 um 19:02 Uhr)

  5. #5
    Benutzer
    Registriert seit
    08.07.2007
    Beiträge
    32
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Beim ZF kann ein Model "n" "Objekte" darstellen.
    Gibt es im Framework überhaupt eine richtige Model-Klasse? Für micht klingt es im Moment so, als wäre ein Model nur eine simple Ableitung der Zend_Db_Table Klasse - ist das so richtig und wird bei einem Model diese Klasse noch irgendwie erweitert, um spezielle Funktionen zu erfüllen (damit beim Löschen z.B. relevante andere Daten mit gelöscht werden)?

    Sagt man nicht, die Logik würde bei MVC im Modell liegen? Das ändert in diesem Fall ja nur die Datenbank - für mich ist das irgendwie keine richtige Logik.. :-(


    Die ominöse Funktion
    getCreditcardsByOwner(..)
    Sieht mir so aus als ob du da ein Beispiel von Relationalem zend DB Zeugs gesehen hast.
    Danke für den Hinweis, dass es solche Funktionen auch im ZF gibt.. Ich hatte diese Namensgebung nur bei diversen anderen Frameworks gesehen. Mit dem DB-Modul wollte ich mich noch nicht beschäftigen, bevor ich nicht MVC richtig verstanden habe, aber nach deiner Definition ist das ja wohl ein und dasselbe. :-|


    Grüße, Florian

  6. #6
    Erfahrener Benutzer Avatar von ChristianFischer
    Registriert seit
    26.04.2007
    Beiträge
    730
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    um spezielle Funktionen zu erfüllen (damit beim Löschen z.B. relevante andere Daten mit gelöscht werden)?
    das ist eben das mit den Relationships. Allerdings ist das nur ne "Krücke" für Datenbanksysteme/Formate die das von Haus aus nicht unterstützen wie MyIsam. Wenn du InnoDB nutzt (bei mysql) kannste das alles auf der Datenbank machen.

    Bei mir sind alle Models von Zend_Db_table abgeleitet. Du kannst dir natürlich auch eigene Model Klassen schreiben. (Seh ich aber keinen Grund dafür)

  7. #7
    Erfahrener Benutzer Avatar von ChristianFischer
    Registriert seit
    26.04.2007
    Beiträge
    730
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Model:
    Das Modell enthält die darzustellenden Daten. Woher die Daten kommen und wie diese zusammenhängen, spielt keine Rolle. So kann es sich hierbei um ein Datenmodell, Geschäftsmodell oder sogar um ein für die Präsentation abstrahiertes Modell handeln. Das Modell kennt weder die Präsentation noch die Steuerung, es weiß also gar nicht, wie, ob und wie oft es dargestellt und verändert wird.

    Controller:
    Die Steuerung verwaltet die Sicht(en), nimmt von ihnen Benutzeraktionen entgegen, wertet diese aus und agiert entsprechend. Sie enthält die Intelligenz und steuert den Ablauf (engl. Workflow) der Präsentation.

  8. #8
    Erfahrener Benutzer Avatar von Blackflash
    Registriert seit
    18.02.2007
    Beiträge
    399
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ich muss ehrlich sagen, dass die Antworten sehr unkonkret sind und viel zu speziell um den MVC-Pattern zu erklären. Natürlich wird man den MVC-Pattern nie in seiner reinen Form finden, wie es im Buche steht, sondern immer mit verschiedenen Mutationen.

    Leider gibt es zu viele verschiedene Möglichkeiten, den MVC-Pattern zu interpretieren, deshalb werde ich jetzt erstmal meine Meinung zu dem komplexen Thema kundtun. Als erstes sehe ich das Modell als Schnittstelle zwischen dem Controller und den Daten. Die Daten können dabei beispielsweise aus einer Datenbank kommen oder einfach nur durch das Modell zurückgegeben werden. Bei mir gibt es für jeden Controller nur ein Modell, auch wenn dieses Datenmodell diverse Tabellen (oder andere Datenquellen) enthalten kann. Wie das Modell intern arbeitet ist einem natürlich selbst überlassen. Meine abstrakte Modellklasse - vielleicht veröffentliche ich sie im Forum, wenn Interesse besteht - enthält die Fähigkeit, eine Vielzahl von Tabellen-Klassen zu speichern, auf die dann innerhalb des Modells zugegriffen werden kann. Man kann dabei die Methoden zum Laden von einzelnen Daten aus bestimmten Tabellen über in die Tabellenklassen kapseln, oder direkt in das Modell. Für mich ist es nur relevant, dass sämtliche interne Vorgänge nicht durch den Controller ausgeführt wird. Er soll also möglichst wenig vom Modell mitbekommen. Dies wäre natürlich nicht gewährleistet, wenn man mehrere Modellklassen hätte.

  9. #9
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ich persönlich würde eher von Zend_Db_Table als Modelschicht abraten, weil diese zu sehr von der Struktur der dahinter liegenden Datenbank abhängt. Ich selbst verwende ein eigenes Objekt mit so lustigen Methoden wie getUser, die allerdings (mittlerweile) Zend_Db_Table verwenden. Müssen sie aber nicht
    Worauf ich hinaus will: Das Model sollte möglichst wenig Rückschlüsse bzw Abhängigkeiten von der dahinter liegenden Datenstruktur besitzen. Wie das nun genau umgesetzt wird, is ... naja, man weiß es nicht

  10. #10
    Abb
    Abb ist offline
    Neuer Benutzer
    Registriert seit
    10.07.2007
    Beiträge
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    nochmal ganz allgemein zum MVC-Prinzip:

    Es gibt 3 Klassen-Bereiche
    Model
    - Die Model-Klassen beinhalten und verarbeiten die Daten

    View
    - Die View-Klassen sind zur Darstellung der Daten.

    Control
    - Die Control-Klassen sind für die Interaktion zuständig.

  11. #11
    Erfahrener Benutzer Avatar von Blackflash
    Registriert seit
    18.02.2007
    Beiträge
    399
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Wow... Ich denke, das hat hier bereits jeder verstanden. Die Frage dreht sich doch darum, wie man den MVC-Pattern am besten implementiert.

  12. #12
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Das VC is ja mehr oder weniger von ZF schon vorgegeben, interessant wirds nun beim Model, welches von ZF zwar Hilfsmittel bekommt, ansonsten aber keine Vorgabe.

  13. #13
    Abb
    Abb ist offline
    Neuer Benutzer
    Registriert seit
    10.07.2007
    Beiträge
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    naja vor ein paar Posts wurde bemängelt, das die Erklärungen nicht allgemein genug seien .. allgemeiner als meine Erklärung wird schwer

  14. #14
    Benutzer
    Registriert seit
    08.07.2007
    Beiträge
    32
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ok vielen Dank für diese vielen, aufschlussreichen Antworten.

    Ich glaube ich werde mich die DB-unabhängige Variante entscheiden, wie sie z.B. von Blackflash oder KingCrunsh erwähnt wurde. Mal sehen wie sich das implementieren lässt.


    Grüße, Floriam

  15. #15
    Erfahrener Benutzer Avatar von budcha
    Registriert seit
    06.06.2007
    Ort
    Berlin
    Beiträge
    363
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Zitat Zitat von KingCrunch Beitrag anzeigen
    Worauf ich hinaus will: Das Model sollte möglichst wenig Rückschlüsse bzw Abhängigkeiten von der dahinter liegenden Datenstruktur besitzen. Wie das nun genau umgesetzt wird, is ... naja, man weiß es nicht
    mmm. eher so: wenn das "model" die daten aus der db holt, machste ne Zend_Db extend version. kommts aus nem text file, nimmste halt "extend My_File_Reader" usw. ein model sollte sich konkret darum kümmern woher es seine daten hohlt. oder sagts du im laufe eine projektes: "mm, die user hab ich bisher immer in meiner file gespeichert, jetzt solls auch aus ner table möglich sein!" dann ändert man nicht das model, sondern kapselt das in nem factory.

    vondaher: wenn deine daten in der db sind, nim zend_db. bastelst du nen model was "eierlegendewollmilchsau" spielt ist das "falsch" (im sinne von: egal ob db, oder file, oder 5 tabellen + eine file, mein model kann alles - abstrakt) da wäre ne factory besser geeignet.

    oder hab ich dich falsch verstanden?

  16. #16
    Benutzer
    Registriert seit
    08.07.2007
    Beiträge
    32
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ich glaube KingCrunsh meinte weniger, dass ein Model alles können sollte, oder besonders abstrakt sein muss.

    Aber "wenig Rückschlüsse auf die DB Struktur" soll wohl Code wie diesen (entnommen aus Ralfs ZF-Tutorial) im Controller verhindern, bei dem das Model einfach nur eine Ableitung von Zend_DB_Table ist:

    PHP-Code:
    private function saveData($data)
    {
        
    $newDate date('Y-m-d H:i:s');
        
    $data['art_user_id'] = '1';
        
    $data['art_cdate'  ] = $newDate;
        
    $data['art_udate'  ] = $newDate;
        
    $article = new ArticleModel();
        
    $art_id $article->insert($data);
        
    $url Zend::registry('router')->getRewriteBase();
        
    $url.= '/article/show/' $art_id;
        
    $this->_redirect($url);

    Da ist m.E. der Sinn vom Model weg. Wenn sich irgendwas an der Struktur der Datenquelle ändert (z.B. Feldname der Tabelle), dann ist man ja bereits gezwungen die ganzen Controller zu ändern (wenn man nicht Dinge tut, an die ich gar nicht erst denken will ("Überschreibung von save() + Ändern des Arrays")^^)..

    Grüße
    Geändert von Floriam (14.07.2007 um 01:46 Uhr)

  17. #17
    Erfahrener Benutzer Avatar von budcha
    Registriert seit
    06.06.2007
    Ort
    Berlin
    Beiträge
    363
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Zitat Zitat von Floriam Beitrag anzeigen
    Da ist m.E. der Sinn vom Model weg. Wenn sich irgendwas an der Struktur der Datenquelle ändert (z.B. Feldname der Tabelle), dann ist man ja bereits gezwungen die ganzen Controller zu ändern (wenn man nicht Dinge tut, an die ich gar nicht erst denken will ("Überschreibung von save() + Ändern des Arrays")^^)..
    mmm. is irgentwie grausig.

    1. ändert sich die table und man muß was im controller ändern isses falsch
    2. um das "billig" zu verhindern würde ich in mein model methoden einbauen die eben die daten liefern/speichern. bei diesem save beispiel würde ich mir vorher überlegen wie man das daten array aufbaut/benennt, in das model kommt die methode "saveArticle" welche dann das array auf die klassen variablen verteilt und das datum generiert usw.

    für genau sowas soll das model da sein. sprich wenn man feststellt das man im controller die daten die gespeichert werden soll so manipuliert das sie praktisch abhängig von der grundlegenden datenstruktur sind (in dem fall field names der table) sollte man sich überlegen ob diese logik nicht in das model gehört (das model ist die anlaufstelle fürs speichern, also auch die anlaufstelle wenn man daten speichert die noch manipulationen benötigen).

    aber trotzdem währe mein model in dem fall ne erweiterung von zend_db_table. gegebenenfalls muß man die insert/update/delete funktionen überschreiben - was nicht schlimm ist sondern imho auch so vorgesehen ist. die zend_db_table ist ja mehr eine unterstützungs klasse die vieles vordefiniert, bei manchen gegebenheiten aber erweitert (überschrieben) werden muß.

    erst wenn durch z.b. konfig parameter es möglich sein soll zwischen verschiedenen speicher methoden (db, file [xml, cvs ..], dummy) zu wählen würde ich halt noch weiter abstrahieren bzw. die entscheidung welches model gewählt wird durch eine factory wählen lassen.

    Zitat Zitat von KingCrunch Beitrag anzeigen
    Ich persönlich würde eher von Zend_Db_Table als Modelschicht abraten, weil diese zu sehr von der Struktur der dahinter liegenden Datenbank abhängt. Ich selbst verwende ein eigenes Objekt mit so lustigen Methoden wie getUser, die allerdings (mittlerweile) Zend_Db_Table verwenden. Müssen sie aber nicht
    Worauf ich hinaus will: Das Model sollte möglichst wenig Rückschlüsse bzw Abhängigkeiten von der dahinter liegenden Datenstruktur besitzen. Wie das nun genau umgesetzt wird, is ... naja, man weiß es nicht
    nochmal durchlesen, denke das die umsetzung im grunde "die selbe" ist, wie ich mir das vorstelle.

    allerdings muß ein model wissen wie es etwas speichern/löschen/updaten soll, vondaher ist der satz "Das Model sollte möglichst wenig Rückschlüsse bzw Abhängigkeiten von der dahinter liegenden Datenstruktur besitzen." etwas verwirrend.

    ich glaube königsmüsli verwendet im grunde eine 2-level model variante. die controller verwenden level 1, wo allgemeine funktionen zur verfügung stehen (getUser, saveUser, ...) und im 2 level wird konkret gesagt wie/wo es zu speichern ist. (level 1 ruft in funktion getUser die find methode von level 2 - extends zend_db_table auf. controller ist es scheiß egal was verwendet wird. level1 beruft sich auf z.b. ein definiertes interface wo die methoden definiert sind, level 2 muß interface benutzen egal ob file oder db verwendet wird.)

    das währe dann "totale beweglichkeit" aber auch mehr konzeptions aufwand (da level1 im grunde factorys sind - aber "viele" methoden evt. enthalten die von aussen aufgerufen werden).

  18. #18
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Nicht alles gelesen ich habe

    Ich meine damit, dass, wenn man Zend_Db_Table einfach erweitert zum Beispiel die Tabellennamen kennen muss. Mit einer eigenen Model-Klasse (oder von mir aus einer erweiterten Table-Class mit eigenen Methoden) mit einer Methode a la getId muss man sich darüber keine Gedanken machen.

    Ich persönlich mache das derzeit über eine eigene Klasse, die (bei Bedarf) erweiterte Table-Klassen ladet (ohne neue Methoden) und darüber dann rumspielt.

    "totale Beweglichkeit", das find ich gut xD

    Im Endeffekt benutze ich ein Mischwesen aus Table-Klassen und gewissermaßen einer "Sammelklasse". Derzeit ist mein Dateisystem statisch auf SQLite ausgelegt, aber mit den ganzen Zend_Db_Adapter_*-Klassen sollte eine Portierung nicht sehr umfangreich werden.

  19. #19
    Erfahrener Benutzer Avatar von Octavian
    Registriert seit
    14.12.2006
    Ort
    Nähe Bonn
    Beiträge
    177
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Bei mir wandert alles in Modelklassen, was mit Zugriffen auf Resourcen wie DB, Dateisystem etc zu tun hat und/oder an mehreren Stellen benötigt wird. Dazu gibt es meistens pro Controller oder Themenkreis eine Modelklasse mit statischen Methoden:
    PHP-Code:
    UserModel::getUserById($id);
    UserModel::getAllUsers();
    GroupModel::getAllGroupsWithUsers();
    GroupModel::deleteGroup($id);
    FileModel::generateDirTree(); 
    und so weiter...

    Somit bereinige ich meine Controller von den ganzen SQL Statements etc und kann mich dort auf die Auswertung konzentrieren.

    Und ich denke auch, dass das der wesentliche Sinn des Models ist, wie genau die Modelklassen dann aussehen (Static wie bei mir oder als Zend_Db_Table Erweiterung) kann ja jeder selbst entscheiden.

  20. #20
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Naja, bei Models find ich statische Klassen etwas unhandlich, weil diese ja nur bedingt Eigenschaften aufnehmen können. Aber ansonsten mach ichs genauso!

Ähnliche Themen

  1. Menu-Model
    Von Timo Trallala im Forum Einsteigerfragen
    Antworten: 13
    Letzter Beitrag: 25.06.2007, 20:24
  2. Kleineres "Gemeinschafts" Projekt
    Von seratio im Forum Installation & Konfiguration
    Antworten: 85
    Letzter Beitrag: 18.06.2007, 13:12
  3. Exception "script 'index/index.phtml' not found"
    Von citystrolch im Forum Einsteigerfragen
    Antworten: 1
    Letzter Beitrag: 31.05.2007, 19:16
  4. welche php "distribution" verwendet ihr?
    Von case im Forum PHP X-Talk
    Antworten: 7
    Letzter Beitrag: 07.05.2007, 19:39
  5. Für was ist das Model?
    Von Bleistift im Forum Einsteigerfragen
    Antworten: 14
    Letzter Beitrag: 30.12.2006, 23:26

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •