[Artemis]

Moin,

ich habe vor, mein Projekt auf Basis des MVC-Musters zu erstellen.
Deshalb frage ich mich, ob ich das ganze auch richtig verstanden habe.

Dazu habe ich dieses kleine Beispiel geschrieben.

PHP-Code:

<?php

class Model_Search
{
    function getResults($search)
    {
        // do some db queries
        
        // fill result array with values - here only for demonstration
        $search_result = array();
        $search_result[] = 'Testseite 1'; 
        $search_result[] = 'Testseite 2';
        
        //return values 
        return $search_result;
    }
}

class View_Search
{
    function displaySearchForm()
    {
        // do some stuff and put out the search form
    }
    
    function displayResults($results)
    {
        // do some stuff and display the values of $results
    }
}

class Controller_Search
{
    function checkSearch()
    {
        // check $_POST values
        
        // if all values are ok then query results and display them
        if ($valuesAreOk)
        {
            $results = Model_Search::getResults($search);
            View_Search::displayResults($results);
        }
        // else show the search form
        else
        {
            View_Search::displaySearchForm();
        }
    }
}

?>

Meine Frage ist nun:

Habe ich das ganze richtig verstanden, oder müsste das ganze anders aussehen?

Thx, Artemis

[Basti]

Hi.

Jo, so etwa kann man das machen. Ich hatte zuerst auch für jede Komponente (MVC-Einheit) je eine Model-Klasse definiert. Das ist aber quatsch, weil man ständig nur rumkopiert. Das Model ist das Datenmodell und es ist geschickt, wenn der Controller dieses direkt ansteuert. Also nicht eine "Model-Klasse", sondern eben alle Objekte, mit denen er arbeitet. (Siehe Beispiel unten)

Dann finde ich es geschickt, wie z.B. bei Symfony die Daten den Views nicht per Parameter zugänglich zu machen, sonden, indem du sie als öffenliche Attribute in den Controllern definierst. In den Views kannst du dann über eine Methode (im einfachsten Fall __get()) direkt auf diese Werte zugreifen (die Methode kodiert diese ggf. um und den Aufruf kannst du z.B. über deine Template-Engine lösen, so dass der Template-Designer nichts davon mitbekommt). Dazu ist es natürlich nötig, dass die View seinen Controller kennt oder irgendwie drauf zugreifen kann. Mit Statischen Klassen ist da also nichts mehr.

Weiter macht es Sinn, im Controller die View nur auszuwählen und diese Auswahl als Rückgabewert zurückzugeben. Mitunter willst du ja nichts anzeigen, sondern einen Redirect machen oder die Anfrage an eine andere Komponente weitergeben. Die Controller zeigen die Views also nicht an, sondern wählen diese nur aus.

Und, weiter wirst du Komponenten auch in einem Baum organisieren wollen, so dass jede Komponente Unterkomponenten einbinden kann. Auch hierfür ist es eben wichtig, dass die Komponente ihre View nicht selbst ausgibt, denn eine Komponente "Page", deren Methode "edit" aufgerufen wurde, könnte z.B. mehrere Komponenten einbinden (z.B. PageImage, Text, Attachments) und kann dann ja erst nach Abarbeitung der letzten Unterkomponente feststellen, dass der Benutzer alles korrekt eingegeben hat. Hier wird sie also einen Redirect machen, andernfalls die Komponenten nochmal anzeigen, um das Formular korrigieren zu können.

Beispiel:

PHP-Code:

<?php

class Component_Page_Controller extends Controller
{
    public $Page; // oeffentliche Variable fuer die View

    public function __construct()
    {
        $sPageId = $this->Request->get('page');
        $this->Page = $this->Persistence->get('Page', $sPageId);  // oder wer auch immer dir die DataObjects bereitstellen kann
    }

    public function action_display()
    {
        return $this->view(); // ohne Parameter = default view
    }

    public function action_edit()
    {
        if ($this->Request->get('save')) {

            $this->Page->set($this->Request['pagedata']);
            if ($this->Page->isValid()) {
                $this->Page->save();
                return $this->redirect($this->sPageId, array('message' => 'edit_success'));
            }
        }
        return $this->view('EditForm');
    }
}
?>

Page.tpl

<h1><?php echo $this->Page->title; ?></h1>
<div><?php echo $this->Page->content; ?></div>

Page_EditForm.php
<form ...>
<?php if (!$this->Page->isValid()) { ?>
    <div class="error">
        <h2>Fehler!</h2>
        <ul>
<?php foreach($this->Page->getErrors as $sError) ?>
            <li><?php echo $sError; ?></li>
<?php } ?>
        </ul>
    <iput type="text" name="pagedata[title]" value="<?php $this->Page->title; ?>"/>
    <textarea name="pagedata[content]"><?php echo $this->Page->content; ?></textarea>
</form>

So etwa könnte das dann aussehen ... natürlich einfacherer mit einer Template-Engine, die dann obigen Template-Code produziert bzw. dann auch ohne __get() die Werte eben über bestimmte Methoden aus dem Controller zieht und Fehler im Template entsprechend behandelt (z.B. nicht gesetzte Properties oder eine Variable für eine Schleife, die kein Array enthält).

Eigentlich reicht auch ein Template als View. Eine Klasse würde ich dann verwenden, wenn hier nochmal bestimmte Daten aus dem oder zusammengetragen oder umgeschrieben weden sollen. Der einzige Zweck läge dann darin, das Template abzuspecken und dem Template-Designer bestimmte Flags etc. zur Verfügung zu stellen.

Natürlich kann dann in so einer View-Klasse z.B.die display-Methode überschrieben werden, so dass garkein Tempalte eingebunden wird, sondern die Daten irgendwie anders ausgegeben werden.

Basti

[Basti]

Zitat von Basti

Dann finde ich es geschickt, wie z.B. bei Symfony die Daten den Views nicht per Parameter zugänglich zu machen, sonden, indem du sie als öffenliche Attribute in den Controllern definierst. In den Views kannst du dann über eine Methode (im einfachsten Fall __get()) direkt auf diese Werte zugreifen (die Methode kodiert diese ggf. um und den Aufruf kannst du z.B. über deine Template-Engine lösen, so dass der Template-Designer nichts davon mitbekommt). Dazu ist es natürlich nötig, dass die View seinen Controller kennt oder irgendwie drauf zugreifen kann. Mit Statischen Klassen ist da also nichts mehr.

Ich frag mich, wie man hier die Unabhängigkeit der Views von den Controllern noch weiter treiben kann. Eigentlich greift die View ja nur auf die Modell-Schicht zu und garnicht auf die Controller. Aber mir ist noch nicht ganz klar, wie sich das umsetzen lässt. Hat da jemand einen gescheiten Ansatz? Alles in die Session oder irgendweinen Container zu packen ist ja auch nichts anderes, als obige Lösung in grün.

Basti

[WarrenFaith]

Ich frag mich, wie man hier die Unabhängigkeit der Views von den Controllern noch weiter treiben kann. Eigentlich greift die View ja nur auf die Modell-Schicht zu und garnicht auf die Controller.

Wasn nun?
Sinn von MVC ist doch, dass View und Model sich nicht kennen und alles nur über den Controller passiert. Demzufolge darf es nur einen Weg geben: Der Controller holt sich Daten aus dem Model und gibt sie dem View.

In den Views kannst du dann über eine Methode (im einfachsten Fall __get()) direkt auf diese Werte zugreifen (die Methode kodiert diese ggf. um und den Aufruf kannst du z.B. über deine Template-Engine lösen, so dass der Template-Designer nichts davon mitbekommt).

Nehmen wir an du willst ein Datum ausgeben. Jetzt müsstest du festlegen, ob das View oder das Model den Timestamp zur Ausgabe in ein "human readable" Format umformt. Das wäre aber definitiv keine Aufgabe für Model oder View, also nur für den Controller.

Dazu ist es natürlich nötig, dass die View seinen Controller kennt oder irgendwie drauf zugreifen kann.

Ne der Controller kennt View und Model; und Model und View kennen nichts!

[Artemis]

Jo, ich denke auch das das so abläuft:
Controller holt sich die Daten aus dem Model, verarbeitet sie und gibt sie dann an den View weiter, welches alles ausgibt.

Dafür müsste nur der Controller wissen, welches Model und welchen View er braucht.

[Basti]

Zitat von WarrenFaith

Wasn nun?
Sinn von MVC ist doch, dass View und Model sich nicht kennen und alles nur über den Controller passiert. Demzufolge darf es nur einen Weg geben: Der Controller holt sich Daten aus dem Model und gibt sie dem View.

Nein, das hast du falsch abgespeichert. Im klassischen MVC holt sich die Präsentationsschicht die Daten prinzipiell aus dem Modell. Der Controller gibt ihr (in der passiven Variante) lediglich die Info, dass er etwas am Modell geändet hat und dass sie sich selbst aktualisieren soll. Im aktiven Modell gibt es noch nichtmal diese Info vom Vontroller, sondern die Views beobachten die für sie relevanten Teile des Models und aktualisieren sich selbst.

Im PHP-Anwendungen ist diese Architektur natürlich quatsch, es sei denn, man speichert den Status (Viewstate), wie z.B. Prado in der Session.

Ich frag mich halt nach einem tauglichen Weg. Denn einerseits finde ich es reizvoll, wenn die Controller den Views nicht alles "vorkauen" müssen (also alle Daten, die diese verwenden können zuvor bereitstellen), auf der anderen Seite ist das mitunter aber der einfachste Weg.

Nehmen wir an du willst ein Datum ausgeben. Jetzt müsstest du festlegen, ob das View oder das Model den Timestamp zur Ausgabe in ein "human readable" Format umformt. Das wäre aber definitiv keine Aufgabe für Model oder View, also nur für den Controller.

Ne der Controller kennt View und Model; und Model und View kennen nichts!

Doch, View kennt Model, denn daher bezieht es seine Daten. So zumindest im klassischen MVC-Pattern. Diese Methode oben wäre quasi eine Art Request-Model, auf die die Views zugreifen. Dass die Daten vom Controller kommen bräuchte die View garnicht interessieren. Aber eben - diese Daten müssen wüssten eigentlich in die Modell-Schicht, aber da fällt mir noch kein besonders sinniger Weg ein.

Zitat von Artemis

Jo, ich denke auch das das so abläuft:
Controller holt sich die Daten aus dem Model, verarbeitet sie und gibt sie dann an den View weiter, welches alles ausgibt.

Dafür müsste nur der Controller wissen, welches Model und welchen View er braucht.

Ja, das ist die klasische Smarty-Vorgehensweise, ist aber nicht MVC. Ist ja auch letztlich Wurscht, nur ertappe ich mich dabei, mitunter in den Controllern Daten aus dem Model zu holen, nur um sie dann in die View zu kopieren (alle Display-Actions machen nichts anderes, falls sie nicht noch andere Komponenten einbinden). Wäre ja einfacher, das im Template zu lösen.

Basti

[WarrenFaith]

Zitat von Basti

Ist ja auch letztlich Wurscht, nur ertappe ich mich dabei, mitunter in den Controllern Daten aus dem Model zu holen, nur um sie dann in die View zu kopieren

Hm, also bisher sind meine MVC-Vorgehensweisen genau so gewesen, nur das der Controller die Daten aus dem Model noch zurechtmacht (formatiert etc) bevor er sie ans View weiterleitet.
Ich werde mal nach einer gescheiten "Anleitung" bzw Einführung ins MVC suchen und dann hier mal vorstellen und diskutieren.
Mal wieder interessantes Thema :)

[Basti]

Hi.

Ich denke, es ist in der PHP-Welt auch absolut üblich, es so zu machen, dass die Controller eben die Daten für die Views zusammenstellen. Zumindest Symphony, WACT, CAKE und andere machen es so. Ob die jeweils noch Mechanismen bieten, direkt auf das Model zuzugreifen, weiß ich nicht. Letztlich ist das ja auch in Ordnung bzw. tauglich und bieet den großen Vorteil, dass Template-Designer nur Zugriff auf Daten haben, die ihnen auch bereitgestellt werden (was natürlich auch wieder ein Nachteil sein kann, wenn ein Entwickler einbezogen werden muss, wenn der Designer da noch eine Info mehr reisetzen mag, die er sich eigentlich selbst aus dem Model ziehen könnte).

Übrigens ist die Darstellung der Zeit in meinen Augen absolut die Aufgabe der View und nicht der Controller. Das Formatieren allgemein packe ich grundsätzlich in die View. Woher soll denn der Controller wissen, ob die Site nachher z.B. utf-8-codiert ist oder in latin 1?

Basti

[WarrenFaith]

Woher soll denn der Controller wissen, ob die Site nachher z.B. utf-8-codiert ist oder in latin 1?

Weil der Controller das festlegt :)
Also ich arbeite so, dass das View die Daten wirklich nur ausgibt. Aufbereitet werden sie über den Controller, denn nur der weiß, in welcher Lokalisierung er die Daten dem View zur Verfügung stellen soll.
Sonst müsste die View ja viel mehr als nur Contentdaten noch vom Model beziehen. Und das würde in meinem Verständnis eher die Rolle des Controllers, der ja nicht nur Datenfluß sondern auch Datenart kontrollieren soll deutlich schmälern. Ich seh da halt nicht dieses Dreipunktekonstrukt sondern eher 3 Schichten in denen der Controller in der Mitte liegt.

[Basti]

Das heißt aber auch, dass du für jede Kodierung je einen Controller brauchst. Das Ganze dann einmal für HTML, einmal für WAP und einmal für Atom oder so...

Ich denke als "Datenart" kann man auch z.B. einen i18n-String oder ein "l10n-Zeitstempel" verstehen. Ich weiß aber noch nicht, was da für mich am Geschicktesten ist. Ich verwende da im Moment eine arge Mischform und bin ständig am umbauen.

Was den Punkt Schichten vs. Punkte angeht, so hat das mit der Thematik aber nichts zu tun. Hierbei geht es ja nur darum, woher die View die Daten bezieht, also ob (ausschließlich) vom Controller oder aus den Models. Der Punkt hier ist ja der, in wie weit die Controller die Daten für die View aufbereiten bzw. ob es die Aufgabe der Controller ist, diese überhaupt irgendwie aufzubereiten, anstatt sie einfach als blanke Datenobjekte zu übergeben.

Mal weg davon, was MVC bzw. Model 2 bedeutet hin dazu, was taugt, würde ich die Verantwortung für die Darstellung trotzdem in jedem Fall in die View-Schicht packen. Das ist bei lokalisierten Datumsormaten für mich eindeutig, z.B. bei mehrsprachigen Texten wiederum nicht so ganz. Ein häufig erwähnter Punkt in dieser Diskussion ist ja z.B. die Sortierung von Listen oder das Aufteilen von Listen auf mehrere Seiten. Eigentlich ganz klar Aufgabe der View, aber prakisch eben mitunter ungünstig, das so umzusetzen. Zumindest, wenn die Controller die Daten zur Verfügung stellen müssten diese ja prinzipiell alle Daten (die komplette Liste) auslesen und das ist ja nicht vertretbar.

Ganz gute Diskussion zur Entwicklung der MVC-Konfusion *g, aber sicher schon bekannt:
http://c2.com/cgi/wiki?WhatsaControllerAnyway

Basti

[WarrenFaith]

Das Ganze dann einmal für HTML, einmal für WAP und einmal für Atom oder so...

Der Controller sagt: die Daten in dem Format und dann das View (WAP, HTML, XML, PDF, ...)
View nimmt die Daten und füttert damit seine Templates oder was auch immer benutzt wird.
Die Steuerung der View übernimmt aber auch der Controller, meiner Meinung nach. Aber da scheiden sich wahrscheinlich wieder die Geister :)

Zum Link: zu lang für die Arbeit :) aber für daheim sicher lesenswert :)

[ex³]

Hallo ich hab selbst mal mit MVC rumprobiert, vielleicht könnt ihr euch mal dazu äußern. Ein News Bereich o. ä. ist nicht vielleicht nicht gerade ein Paradebeispiel, aber schaut euch das mal an und kommentiert was dazu.

Dann wäre nochwas
Wie bringt man in diesem Konzept denn ein error handling mit exception am geschicktesten unter?
und ist es wirklich nötig Funktionen,etc. statisch zu machen oder mit Referenzen zu arbeiten also :: oder &=
Ich denk doch mit PHP5 ist das doch egal oder ;)

PHP-Code:

<?php
class NewsView {

    public function getView(Array $newsposts) {
        echo '<pre>';
        print_r($newsposts);
        echo '</pre>';
    }
}
?>

PHP-Code:

<?php
class NewsModel {

    private $mdb2 = null;

    public function NewsModel(MDB2_Driver_Common $mdb2) {
        $this->mdb2 = $mdb2;
    }

    public function getNewsposts() {
        $data = $this->mdb2->queryAll('SELECT n.id, n.seo, n.title, n.post, n.postdate, n.author, ' .
        'COUNT(c.id) AS comments ' .
        'FROM newspost AS n ' .
        'LEFT JOIN newscomment AS c ON n.id = c.newsid ' .
        'WHERE n.postdate < ' . $this->mdb2->quote(time()) . ' AND n.textstatus = 1 ' .
        'GROUP BY n.id ' .
        'ORDER BY n.postdate DESC LIMIT 0, 5');

        if (PEAR :: isError($data)) {
            die($data->getMessage() . ' - ' . $data->getUserinfo());
        }

        return $data;
    }
    

}
?>

PHP-Code:

<?php

require_once 'lib/NewsModel.php';
require_once 'lib/NewsView.php';

class NewsController {

    private $model = null;
    private $view = null;
    
    public function NewsController(MDB2_Driver_Common $mdb2) {
        $this->model = new NewsModel($mdb2);
        $this->view();
    }
    
    public function view() {
        $this->view = new NewsView();
        
        $newsposts = $this->model->getNewsposts();
        
        $this->view->getView($newsposts);
    }
}
?>

[Chr!s]

Grundsätzlich ist es beim MVCModell so, dass du ein View, ein Controller und ein Model hast. Hier mögen die Geister zwar schon ausseinandergehn, jedoch halt ich dies sehr sinnvoll. Die News von denen du sprichst, wäre dann ein "Modul".

Du kannst soviele Module haben wie du möchtest und brauchst - es existiert dennnoch nur ein View, ein Model und ein Controller.
Dein Modul macht dann z.B. folgendes:

PHP-Code:

<?php
class Modul_news {
        public function renderNewsOfTheDay() {
                $this -> oModel -> fetch("SELECT ...");
                // Daten verarbeiten

                $this -> oView -> load('newsOfTheDay.tpl');
                $this -> oView -> assign('...', '..');
                $this -> oView -> render();
        }
}
?>

Ist natürlich jetzt nur eine Art und Weisen, den View zu implementieren.
(So setze ich jedenfalls das MVCModell um )

[WarrenFaith]

hm... ich denke aber das jedes Modul einen eigenen Controller verdient hat oder nicht?
Je nachdem wie du dein View/Model aufbaust, dürftest du auf Probleme stoßen, sobald du mehr als HTML ausgeben willst bzw mehr als nur via MySQL deine Daten speicherst.

Allerdings ist Model/View wie von ex³ getan auch nicht sinnvoll, denn dein View/Model sollte nicht vom Modul abhängen, sondern von der Aufgabe. Hast du ein View_HTML z.B. dann können damit fast alle Module arbeiten. Mit dem Model das gleiche (Model_MySQL). Lediglich der Controller sollte einmal pro Modul existieren, da die Arbeitsweisen einfacher sind.

Doppelt gemobbelter Post aber egal :P

[Basti]

Zitat von Chr!s

Grundsätzlich ist es beim MVCModell so, dass du ein View, ein Controller und ein Model hast. Hier mögen die Geister zwar schon ausseinandergehn, jedoch halt ich dies sehr sinnvoll.

Oh, da will ich gleich widersprechen.*g

Weniger interessant, ob das nun MVC ist (dem ich auch widersprechen würde), sondern vielmehr, ob das sehr sinnvoll ist. Bei mir hat ein "Modul" in der Regel zumindest zwei Views (anzeigen und bearbeiten), weitere Views zum Hinzufügen, Auflisten aller Datensätze, Bestätigen vor dem Löschen etc. kommen da aber schnell noch dazu.

Dazu greifen Controller mitunter auf Aspekte/Objekte des Modells zurück, die nicht explizit dem Modul zugeordnet werden können. Um beim Beispiel hier zu bleiben: In meinem CMS gibt es z.B. ein Modul, eine Seitenkomponente "Teaser", die beim veröffentlichen von neuen Seiten(-Versionen) News erzeugen kann. Sowohl das Teaser-Modul, als auch das News-Modul (das alle News darstellt) greifen auf das gleiche "Model" zurück. Ebenso die Navigarionselemente, die alle auf die "Sitemap" (sozusagen) zugreifen.

Es gäbe sehr viele Redundanzen, wenn jedes Modul seine eigene Model-Klasse hätte. Zuerst hatte ich das auch so, aber das hat sich nicht bewährt.

Und, was die Controller angeht: Natürlich brauchen diese verschiedene Views, mit denen sie arbeiten können. Klassisches Beispiel: Wenn Formular-Request valide, dann mach eine Weiterleitung zu der und der Sicht, andernfalls zeig das Formular nochmal an.

Ist ja auch immer die Frage, was denn nun Controller genannt wird. In der Regel ist das in PHP-Anwendungen ja so eine Klasse in der alle Actions eines Moduls versammelt sind. Mitunter bekommt jede dieser Actions auch eine eigene Klasse oder Frameworks bieten beide Möglichkeiten an.

PHP-Code:

<?php
class Modul_news {
        public function renderNewsOfTheDay() {
                $this -> oModel -> fetch("SELECT ...");
                // Daten verarbeiten

                $this -> oView -> load('newsOfTheDay.tpl');
                $this -> oView -> assign('...', '..');
                $this -> oView -> render();
        }
}
?>

Bis auf die Bezeichnung der Methode (und dass hier direkt SQL verwendet wird, anstatt sich die entsprechenden Objekte geben zu lassen) kann ich dem zustimmen. Bei mir siehts halt so aus:

PHP-Code:

<?php

class Mod_News extends PageComponent
{
    protected $Manager;

    public $iNumNews;
    public $aNews;

    protected function init()
    {
        $this->Manager = $this->Persistence->getManager('News');
    }

    public function selectDisplayView()
    {
        $this->iNumNews = $this->Config->get('numNews');
        $this->aNews = $this->Manager->getNews($this->iComponentId, $this->iNumNews);
        $this->setView('Display');
    }

    public function selectEditForm()
    {
        $this->aNews = $this->Manager->getNews($this->iComponentId);

        $this->setView('EditForm');
    }
// ...
}

// und das Teaser-Modul:

<?php

class Mod_Teaser extends PageComponent
{
    protected $Manager;
    public    $News;

    public function init()
    {
        $this->Manager = $this->Persistence->getManager('News');
    }

    public function selectEditForm()
    {
        $this->recieveNews();
        $this->setView('EditForm');
    }

// ...

    protected function recieveNews()
    {
        $this->News = $this->Manager->get($this->iComponentId);

        if (is_null($this->News)) {
            $this->News = $this->Manager->create();
            $this->News->id = $this->iComponentId;
        }
    }

...sind aber auch nochmal spezielle Komponenten, diese PageComponents.

Zitat von ex³

Wie bringt man in diesem Konzept denn ein error handling mit exception am geschicktesten unter?

Was meinst du?

und ist es wirklich nötig Funktionen,etc. statisch zu machen oder mit Referenzen zu arbeiten also :: oder &=
Ich denk doch mit PHP5 ist das doch egal oder ;)

Referenzen bekommst du automatisch, solange du nicht klonst und statische Methoden sind ein ganz anderer Stiefel. Wozu brauhst du die?

PHP-Code:

<?php
class NewsView {

    public function getView(Array $newsposts) {
        echo '<pre>';
        print_r($newsposts);
        echo '</pre>';
    }
}
?>

Eine Methode getIrgendwas() solle auch was zurückgeben und nichts ausgeben. Dann würde ich eher fr jede View eine eigene Klasse definieren, anstatt eine generelle Klasse NewsView zu benutzen, in die dann alle Views reinmüssen. So kannst du die Klassen denn dann ggf. auch komplett weglassen und nur ein Template verwenden.

PHP-Code:

<?php
class NewsModel {

    private $mdb2 = null;

    public function NewsModel(MDB2_Driver_Common $mdb2) {
        $this->mdb2 = $mdb2;
    }

    public function getNewsposts() {
        $data = $this->mdb2->queryAll('SELECT n.id, n.seo, n.title, n.post, n.postdate, n.author, ' .
        'COUNT(c.id) AS comments ' .
        'FROM newspost AS n ' .
        'LEFT JOIN newscomment AS c ON n.id = c.newsid ' .
        'WHERE n.postdate < ' . $this->mdb2->quote(time()) . ' AND n.textstatus = 1 ' .
        'GROUP BY n.id ' .
        'ORDER BY n.postdate DESC LIMIT 0, 5');

        if (PEAR :: isError($data)) {
            die($data->getMessage() . ' - ' . $data->getUserinfo());
        }

        return $data;
    }
    

}
?>

Ich würd mich an der Stelle nicht so derb festlegen (MDB2, PEAR), wenns ach sicher einiges schneller ist, so zu arbeiten. An der Stelle würde ich mir ein DAO erzeugen lassen, dass die Datenquelle kennt und mir von ihm ein TransferObject mit den News-Einträgen übergeben lassen. Daraus würd ich dann eine Objektliste mit den News-Einträgen erzeugen lassen und zurückgeben.

Auch die DAOs machen bei mir nicht das Escaping, sondern übergeben lediglich Query und Daten getrennt an die Verbindungs-Klasse.

Vorteile davon:
- Alle Queries liegen an einem zentralen Ort und können ggf. leicht ausgetauscht werden;
- Die Schnittstelle zu den Daten bleibt über die DAOs immer gleich, auch wenn sich das DBMS oder sonstwas in der Datenstruktur ändert;
- Arbeit mit Objekten, anstatt mit Arrays; DataObjects können einfach verändert und über ihre Methode save() gespeichert werden;

Nachteile:
- Aufwändig zu implementieren (vor allem, wenn man gewährleisten will, dass jeder Datensatz nur einmal zur Laufzeit in einem Objekt existiert);
- Braucht natürlich mehr Ressourcen...

Basti

PS:
Kennst du __construct()?

[Chr!s]

Basti ich glaub dass wir ein bisschen aneinander vorbeireden..
Mit "View" hab ich eigentlich die Umgebung gemeint, die meine Views verwaltet - sprich bei dir wäre das $this -> setView bzw PageComponent. Natürlich gibts bei mir auch mehrere Views - zum bearbeiten, löschen, auflisten, anzeigen, etc, aber eine Umgebung, die mir die Views zusammenbastelt

Was mich aber bei deinem Beispiel jetzt interessieren würde

PHP-Code:

<?php
    public function selectEditForm()
    {
        $this->aNews = $this->Manager->getNews($this->iComponentId);

        $this->setView('EditForm');
    }
?>

Da geht es dann schon aber weiter, oder? Wenn nein, woher holt sich dein View dann die Variablen? Ich hab nämlich das Problem das Ganze noch recht umständlich gelöst zu haben ($oView -> assign(...)) ,was bei vielen Variablen sehr lästig ist (auch wenn ich ein multiAssign(array(), array()) ) benutzen könnte..

[Basti]

Mod_News::aNews ist public und so kann aus der View direkt drauf zugreifen. Hab das glaub ich bei Symfony zuerst gesehen und hat mir gut gefallen, da es einfach sehr einfach ist. In den Views gibt es dann sogar einen getter, der direkt auf die Controller-Properties zugreift. Dort ist dann also nurnoch ein $this->aNews nötig, um auf die Daten zuzugreifen.

Allerdings ist das dann schon wieder arg ausgereizt und fehleranfällig etc. Das werd ich spätestens ändern, wenn ich meine Template-Engine fertig hab, hinter der dann die konkrete Implementierung, wie an die Daten zu kommen ist, eh versteckt werden.

Basti

PS:
Eine View ist übrigens schon eine Sicht, also entweder das Formular xyz oder die Liste oder ...

[ex³]

Hm...also das klingt alles schon ganz einleuchtend. __construct ist klar, get Methoden klar, das Restliche muss ich noch verdauen.

Da wäre nochwas wenn ich Daten zurückgeben unter getNewsposts() sollte ich dafür nochmal eine Klasse Newspost anlegen?

Ich meine die Daten kämen dann aus $data und würden dann in sowas landen

$newsposts[] = new Newspost($data);

denk ich mir mal.

Sollte man für Daten die man zurückgibt extra nochmal Objekte erzeugen? Anscheinend ist ein Array von Newseinträgen nicht so geschickt wie ein Array von Newspost Objekten...
Wo sollte dann die Formatierung stattfinden bsp. von Timestamps, Beträge? In der View? Oder im Newsobjekt beim getNewspostContent() oder so?

[WarrenFaith]

Wo sollte dann die Formatierung stattfinden bsp. von Timestamps, Beträge? In der View? Oder im Newsobjekt beim getNewspostContent() oder so?

Je nachdem wie streng man das trennt sollte eigentlich der View nur Daten bekommen und diese "ausgeben", sprich Formatierungen für Datum etc findet vorher statt.

[Basti]

Hi.

Zitat von ex³

Sollte man für Daten die man zurückgibt extra nochmal Objekte erzeugen?

Ist halt, wie gesagt teurer. Aber hat eben den Vorteil, das sich solche DataObjects einfacher habhaben lassen, als das alles mit Arrays zu machen.

Mit Arrays schiebst du immer irgendwelche Datenhäppchen hin- und her, anstatt eben ein in sich stimmiges Objekt zu haben, das du verändern, speichern, löschen, als Ganzes anderen Methoden übergeben kannst oder über das du an weitere Infos rankommst.

Aber, das ganze Thema ORM ist nicht ohne und ich z.B. hab mir einigen Ärger eingeheimst, hier nicht auf eine bereits bestehende Lösung zu setzen und meine eigene Lösung nicht konsequent durchgetetstet zu haben. Es gibt halt ruckzuck sehr viel mehr Fehlerquellen mehr. Bei mir werden z.B. alle Datenobjekte eines Typs von einem bestimmten Manager verwaltet. Werden Datensätze nur unvollständig ausgelesen, so werden dennoch entsprechende DataObjects erzeugt und eben nachgeladen, sobald auf ein Attribut zugegriffen wird, das noch nicht ausgelesen wurde. Das an sich ist schon ein heikler Punkt.

Oder was, wenn die DataObjects in die Session wandern? Wie werden IDs behandelt? Was, wenn ein DataObject gespeichert werden soll, das garnicht verändert wurde (der enstprechende Status muss also espeichert werden)? Wann ist ein DataObject valide? Ich speichere z.B. neue Seiten-Entwürfe in meinem CMS auch dann ab, wenn diese noch nicht valide sind. Zur Veröffentlichung reichsts also noch nicht, wohl aber zum Speichern in der Datenbank. Andererseits gibt es z.B. eine Routine, die für alle DataObjects vor dem speichern prüft, ob alles valide ist und das speichern ggf. ablehnt. Wohin also damit?

Der Punkt wird dann nochmal interessanter, wenn nicht nur die Datensätze durch Objekte repräsentiert werden, sondern auch die Attribute. Das hat den großen Vorteil, der einfachen Validierung (jedes Datantyp-Objekt prüft, ob es in sich valide ist und das DataObject iteriert so erstmal nur über alle Attribute, um zu sehen, ob es valide ist (vor den weiteren Prüfungen, die ja ggf. noch azukommen)). Auch kannst du so die Werte gleich korrekt formatiert zurückbekommen. Vom Typ des Wertes, der ja sonst, wenn er aus der DB kommt in der Regel nur ein String oder null ist, bis hin zu automatischer Erzeugung von Input-Feldern in Formularen ist da einiges möglich.

Das ist halt ein ganzer Haufen an Komplexität, den du damit wegschaffst. Aber ich finde den Weg ziemlich mühsam, bis dieser Haufen sauber verstaut ist.

Also vielleicht einfach mal Propel oder so anschauen.

Basti