Verständniss MVC

[paddelx3]

Heyho Com.

Habe eig nur ein paar Verständnissfragen zum MVC Modell.

MVC steht für
Model _ kümmert sich um die besorgung der Daten
View _ Erzeugt den HTML Code / Die Ausgabe die an den User gereicht wird
Controller _ Verbindet das Model mit den View und teilt die Aufgaben zu.

Ordner Struktur

model
-index.model.php
view
-index.view.php
controller
-index.controller.php
lib
-bootstrap.php

index.php

Nach meiner Wahrnehmung intialisiert die Bootstrap Datei, die von der Index.php aufgerufen wird, den Controller.
Dieser wiederum handelt das Model und die View, die die Daten dann via z.b. render() methode wiedergibt.

Währe mein Verständiss von MVC Ansatzweise richtig? falls nicht bitte Rückmeldung geben was ich falsch verstanden habe.

[Ravenstorm]

Ja, das ist richtig.

Die Seite selbst (index.php) triggert eine Funktion innerhalb der lib (bootstrap.php) welche eben dann einen Ablauf definiert und z.B. Eine Funktion vom Controller aufruft dieser brauch z.B. eine DB-Verbindung und baut diese durch das Model auf, danach kann er natürlich einfach eine Ausgabe mit den Daten tätigen und führt somit die Funktion in der View aus.

[paddelx3]

Alles klar, vielen dank. )
Wie ist das jetzt wenn ich z.b. noch nen Datenbank Modul einbauen möchte.
Sollte ich eine neue Klasse schreiben und diese dann via z.b. load_module() funktion (als Beispiel) in das Model laden?

sprich sowas in der Art.

PHP Code:

class indexmodel{
     // Funktionen etc..
    function load module($module) {
          // Prüfen ob Datei vorhanden und das "modul" includieren...
          $this->$module = new $module();
    }
} 


Das ich in den Index Model praktisch gesehen nochmal eine Var. für die DB festlege und dieses Modul dann z.b. via

PHP Code:

$this->db->run_query('SELECT blablabla FROM TBL_BLABLABLA'); 


anspreche?
oder würdest du es anders lösen?

[Ravenstorm]

Ich würde das folgendermaßen legen...
Eine Funktion für die Conn im Model um eine Connenction auf zu bauen. Dann im Controller eine Funktion welches uns allgemein Prepared-Statements abgeben lässt und ebnen Funktionen um nach einem Select entweder ein Field zu selecten oder eben ein Tabelle und das dann entweder als Variable(Wert) übergeben oder als Array(Werte-Feld).

Ich bin nicht so ganz schlau geworden aus deiner Frage deswegen habe ich einfach mal ein Beispiel dazu gepackt. War das so gemeint?

[dowhile]

Eine Funktion für die Conn im Model um eine Connenction auf zu bauen. Dann im Controller eine Funktion welches uns allgemein Prepared-Statements abgeben lässt und ebnen Funktionen um nach einem Select entweder ein Field zu selecten oder eben ein Tabelle und das dann entweder als Variable(Wert) übergeben oder als Array(Werte-Feld).

Für was brauche ich das Model dann überhaupt? Wenn das eh nur als Brücke zwischen Datenbank API und Controller ist kann ich das doch auch auslassen.
(Ich beziehe mich insbesondere auf den Teil deiner Aussage, dass die Statements im Controller angegeben werden.)

[Ravenstorm]

Originally Posted by dowhile

Für was brauche ich das Model dann überhaupt? Wenn das eh nur als Brücke zwischen Datenbank API und Controller ist kann ich das doch auch auslassen.
(Ich beziehe mich insbesondere auf den Teil deiner Aussage, dass die Statements im Controller angegeben werden.)

Du scheinst das ganze nicht verstanden zu haben und somit möchte ich dir hiermit mal eine kleine Verdeutlichung meines Textes geben:

View.php - Hier sind unsere Funktionen welche uns wirklich die richtigen Sachen zeichnen wie z.B. eine formatierte Tabelle

Model.php - Aufbau der Connection -> Schaffen eines DBKommunikators um den Result direkt in der richtigen Form zu kriegen.

Controller.php - Hier sind unsere Utils vorhanden, sie erhalten die Daten aus z.B. einer Funktion welche in Verbindung mit dem DBKommunikator benutzt worden ist -> z.B. Zeichnung eines TextFeldes, Zeichnung einer DropDownBox, String-Validierung und gibt diese Funktionen sind somit aufrufbar in der View


Und dann haben wir unsere normalen Files, welche im Konstruktor erstmal 2 TextFelder schafft dank dem Controller ist das ja relativ einfach und und mit über den DBKommunikator holst du dir nun die Daten in dem Format in dem du sie haben möchtest, und lässt dir somit deine tabelle über die view mit dem Resultat zeichnen.

[Synatex]

Dein Model ist quasi die API zwischen Controller und View wie du schon sagtest. Es enthält eigentlich nur die Daten und gibt die an den View weiter.

Beispiel:
- Ich frage Userdaten aus Tabelle ab und gebe sie auf dem Bildschirm aus

Controller.php
- Connect() - Stellt Verbindung zur Datenbank her (Wobei die meisten Frameworks da auch wieder Objekte zu bieten)
- getUserData() - Fragt die Daten mithilfe von der Connect() ab

Model.php
$data = $this->getUserData(); - Benutzt die Controllerfunktionen um die Daten zu sammeln

View.php
<h1><?php $this->data['username']; ?></h1> - Gibt dann den Usernamen aus dem im Model deklarierten $data Array wieder zurück.

Mehr ist das nicht.

[dowhile]

Irgendwie werde ich aus deiner Aufteilung noch immer nicht so ganz schlau. Du siehst also Model / View / Controller jeweils nur als universelle Funktionssammlung, auf die du dann von anderer Stelle zugreifst um die Seiten zu erstellen?
Welche Vorteile hast du davon?

Wenn das Model nur die Datenbankverbindung aufbaut und auf SQL Statements wartet habe ich dadurch doch absolut keine Flexibilität; der Rest der Anwendung muss trotzdem noch genau wissen, in welcher Form die Daten gespeichert sind.

Wenn das View konkrete Methoden wie zeichneElementX() besitzt kapsel ich damit doch die Darstellung gar nicht. An der Stelle, an denen ich diese Funktionen dann aufrufe, bestimme ich doch noch immer wesentlich wie das dann aussieht.

Ist der Gedanke hinter MVC nicht eher ...
* Model: Kapselt den gesamten Datenzugriff, sodass sich die restliche Anwendung keine Gedanken darüber machen muss; sprich: Methoden wie "holeBenutzerX()", "holeNachrichten(benutzer)", ...
* View: Entscheidet komplett selber, wie irgendwelche Daten dargestellt werden, sprich: Der Controller sagt "visualisiereDaten(daten)" und hat keine Ahnung, ob die nun als Tabelle, als Formular oder sonst irgendwie dargestellt werden.
* Controller: Je nach Implementierung: Kontrollfluss/ Geschäftslogik.

... sodass ich dann nur, wenn sich die Datenstruktur irgendwie verändert, nur das Model anpassen muss und, wenn sich die Darstellung ändert, nur das View bearbeiten muss. Bei deiner Erklärung fällt das doch irgendwie raus, bei solchen typischen Anwendungen wären noch immer viele Stellen betroffen. Oder verstehe ich dich komplett falsch?

[Ravenstorm]

Originally Posted by dowhile

Irgendwie werde ich aus deiner Aufteilung noch immer nicht so ganz schlau. Du siehst also Model / View / Controller jeweils nur als universelle Funktionssammlung, auf die du dann von anderer Stelle zugreifst um die Seiten zu erstellen?
Welche Vorteile hast du davon?

Wenn das Model nur die Datenbankverbindung aufbaut und auf SQL Statements wartet habe ich dadurch doch absolut keine Flexibilität; der Rest der Anwendung muss trotzdem noch genau wissen, in welcher Form die Daten gespeichert sind.

Wenn das View konkrete Methoden wie zeichneElementX() besitzt kapsel ich damit doch die Darstellung gar nicht. An der Stelle, an denen ich diese Funktionen dann aufrufe, bestimme ich doch noch immer wesentlich wie das dann aussieht.

Ist der Gedanke hinter MVC nicht eher ...
* Model: Kapselt den gesamten Datenzugriff, sodass sich die restliche Anwendung keine Gedanken darüber machen muss; sprich: Methoden wie "holeBenutzerX()", "holeNachrichten(benutzer)", ...
* View: Entscheidet komplett selber, wie irgendwelche Daten dargestellt werden, sprich: Der Controller sagt "visualisiereDaten(daten)" und hat keine Ahnung, ob die nun als Tabelle, als Formular oder sonst irgendwie dargestellt werden.
* Controller: Je nach Implementierung: Kontrollfluss/ Geschäftslogik.

... sodass ich dann nur, wenn sich die Datenstruktur irgendwie verändert, nur das Model anpassen muss und, wenn sich die Darstellung ändert, nur das View bearbeiten muss. Bei deiner Erklärung fällt das doch irgendwie raus, bei solchen typischen Anwendungen wären noch immer viele Stellen betroffen. Oder verstehe ich dich komplett falsch?

Du scheinst es, wie du bereits selbst sagtest, nicht verstanden zu haben was ich meine. Synatex hat das schön erklärt ohne große Beispiele.