MySQL - eintragen von Daten geht schief... (Seite 4)

Mit dem Groß deiner Aussagen stimme ich überein.
Darüber hinaus besteht IMHO bei folgenden Regeln des Softwaredesigns Einigkeit:

• Wiederverwendbarkeit ist besser als Duplizierung.


• Kapselung von Daten und Algorithmen in Klassen.


• Programmierung gegen Schnittstellen, die so entwickelt sind, dass man sie jederzeit erweitern kann (Flexibilität)



• Vermeidung fester Abhängigkeiten zwischen einzelnen Klassen, stattdessen lose Kopplung.

Das wiederum wirft nun aber einige Fragen auf bzgl. deines Beispieles:
<?php
private function _newPost() {
$table = $this->_getTable(\'Comments\');
$table->bind(Request::getString(\'newComment\',\'array\'));
$table->store();
}

Fehlender Parameter
Warum übergibst du die zu speichernden Daten nicht per Parameter? Wenn du irgendwo ein anderes Formular hast, mit dem du das Kontaktformular füllen kannst und bei dem das Feld nicht \'newComment\' heißt, benötigst du eine zwei Methode:
<?php
private function _newPost2() {
$table = $this->_getTable(\'Comments\');
$table->bind(Request::getString(\'newComment2\',\'array\'));
$table->store();
}

Sinnvoller wäre es hier IMHO, den Inhalt des Kommentars als Parameter zu übergeben:
<?php
private function _newPost($comment) {
$table = $this->_getTable(\'Comments\');
$table->bind($comment);
$table->store();
}
Denn, wie bereits gesagt, deine Speichermethode sollte nicht wissen müssen, wo die Daten herkommen.

Unnötige Kopplung
Warum verwendest du in deinem Beispiel eine statische Request-Klasse? Du schaffst damit jede Menge Abhängigkeiten und blockierst dir Möglichkeiten.

Sinnvoller wäre hier IMHO ein normales Objekt das über eine Helfer-Methode geholt wird (ähnlich deiner _getTable-Methode):

<?php
private function _newPost() {
$table = $this->_getTable(\'Comments\');
$table->bind($this->_getRequest()->getString(\'newComment\',\'array\'));
$table->store();
}

Somit hättest du auch im Nachhinein noch die Möglichkeit, dein Request-Objekt problemlos gegen ein anderes Request-Objekt auszutauschen.


Worauf ich hinaus will: OOP schafft viele Vorteile, aber man benötigt eine gewisse Disziplin und Konsequenz bei der Umsetzung. Wenn die Flexibilität verloren geht, dann gegen auch die meisten Vorteile von OOP verloren.

Ich stimm dir voll und ganz zu, aber wo ist der Unterschied zwischen
<?php
$comment = Request::getString(\'newComment\',\'array\');
$table->bind($comment);
?>
und
<?php
$table->bind(Request::getString(\'newComment\',\'array\'));
?>
???

Der Operation wird in beiden Fällen ein Array übergeben mit den Werten.
Ich verwende die Statische Klasse Request weil ich sie überall brauch, wenn du ein Objekt hast musst du die Gültigkeitsbereiche beachten und dir immer wieder eine Referenz auf das Objekt holen um damit zu arbeiten. Das ist vom Prinzip her überflüssig.

Das Beispiel macht keinen Unterschied, wohl aber folgendes:


<?php
protected function _createComment()
{
$this->_helper->model(\'Comment\')->createComment(
$this->getRequest()->getParam(\'comment\'));
}

public function createAction()
{
$this->_createComment();
}

protected function _createComment2()
{
$this->_helper->model(\'Comment\')->createComment(
$this->getRequest()->getParam(\'text\'));
}

public function commentAction()
{
$this->_createComment2();
}


Im Vergleich dazu:

<?php
protected function _createComment($comment)
{
$this->_helper->model(\'Comment\')->createComment($comment);
}

public function createAction()
{
$this->_createComment(
$this->getRequest()->getParam(\'comment\'));
}

public function commentAction()
{
$this->_createComment(
$this->getRequest()->getParam(\'text\'));
}


Es geht letztendlich um möglichst lose Kopplung und Vermeidung von Duplizierungen.

Was die Request-Klasse angeht: Das Holen der Referenz ist nur auf den ersten Blick überflüssig, wenn man genauer hinschaut, dann ist es eine Notwendigkeit. Durch das nutzen einer statischen Klasse schaffst du eine enge Bindung der Request-Klasse an den Controller (oder wo auch immer du sie benutzt). Das führt aber spätestens dann zu Problemen, wenn du die Request-Klasse austauschen möchtest (z.B. zur Durchführung von Unit-Tests). Dann musst du nämlich entweder die Request-Klasse abändern oder an allen Stellen einen Switch einbauen. So oder so ist dein Design nicht flexibel genug.

Jetzt weis ich was du meinst!
Du kennst dich wirklich ziemlich gut aus, nicht schlecht.

Gruß Thomas