Fehlerhafter CakePHP-Code: Die 6 häufigsten Fehler, die CakePHP-Entwickler machen

CakePHP ist ein erstaunliches PHP-Framework, aber es hat eine steile Lernkurve! Es erfordert eine Menge Forschung und Training, um ein Experte zu werden.

Ich habe das Glück, CakePHP jetzt seit über 7 Jahren zu verwenden, und in dieser Zeit hatte ich die Ehre, mit vielen Mitgliedern der CakePHP-Community zusammenzuarbeiten.

In diesem CakePHP-Tutorial möchte ich einige schlechte Praktiken beschreiben, die ich im Laufe der Jahre gesehen habe, und den richtigen Ansatz vorschlagen, um diese Fehler zu vermeiden. Das soll nicht heißen, dass mein Code perfekt ist, aber als Programmierer lernen wir immer dazu, daher ist es wichtig, die bewährten Methoden zu befolgen und sich beim Lernen anzupassen!

Der Inhalt dieses Artikels ist von einem Beitrag von CakeCoded inspiriert. Wenn Sie mehr über CakePHP erfahren möchten, besuchen Sie bitte unseren Lernbereich hier.

Häufiger Fehler Nr. 1: CakePHP-Codierungskonventionen nicht befolgen

Die CakePHP-Codierungskonventionen können hier eingesehen werden. Ich werde ein paar Dinge hervorheben, die mir oft auffallen, wenn ich mir den Code anderer Programmierer anschaue.

Kontrollstrukturen. So oft sehen Sie, dass Programmierer dies falsch machen und in einigen Fällen Praktiken aus anderen Programmiersprachen mitbringen. CakePHP erwartet die folgende Syntax:

 if ((expr_1) || (expr_2)) { // action_1; } elseif (!(expr_3) && (expr_4)) { // action_2; } else { // default_action; }

Es sollte 1 (ein) Leerzeichen vor der ersten Klammer und 1 (ein) Leerzeichen zwischen der letzten Klammer und der öffnenden Klammer geben. Das bedeutet also, dass Folgendes falsch ist:

 if($this->request->data){ }

Beachten Sie den Abstand zwischen if und ( , and between ) und {

Verwenden Sie in Kontrollstrukturen immer geschweifte Klammern, auch wenn sie nicht benötigt werden. Sie erhöhen die Lesbarkeit des Codes und führen zu weniger logischen Fehlern.

So ist beispielsweise Folgendes falsch:

 if ($foo) $bar = true

Diese sollte wie folgt formatiert sein:

 if ($foo) { $bar = true }

Achten Sie schließlich darauf, wo Sie die Klammern platzieren. Öffnende Klammern sollten keine neue Zeile beginnen. Und stellen Sie sicher, dass alle Ihre Klammern so ausgerichtet sind, dass jede neue Klammer mit der schließenden Klammer übereinstimmt.

Hier sind einige falsche Beispiele:

 if ($foo) { $bar = true; }

Das ist falsch, die öffnende Klammer sollte in der ersten Zeile stehen:

 if ($foo) { $bar = true; if ($action) { $to = false; } }

Die Einkerbung muss korrekt ausgerichtet sein.

Ich höre Programmierer oft sagen: „Aber ich bin zu beschäftigt, um den Code sauber zu machen …“. Meine Antwort ist: „Vertrauen Sie mir, ordentlicher Code wird die Zeit überdauern“. Das Schreiben von CakePHP-Code, der nicht lesbar ist, wird ein Alptraum sein, wenn Sie in ein paar Monaten eine Änderung vornehmen müssen.

Häufiger Fehler Nr. 2: Unsachgemäße Verwendung von beherrschbaren Verhaltensweisen und rekursiven Ebenen in ORM

Ich hatte das Glück, kürzlich eine informelle Diskussion mit einem Datenbankentwickler von Facebook zu führen. Wir fingen an, über CakePHP zu sprechen, und er sagte zu mir: „Oh, das verwendet ORM, nicht wahr? Das kann beängstigend sein.“ Ich fragte ihn, was er meinte, und er meinte, dass es bei objektrelationalem Mapping (ORM) leicht sei, dass SQL-Abfragen unnötig groß würden.

Er hat in gewisser Weise recht. Ein Teil der Magie von CakePHP liegt in der Verwendung von ORM und der Art und Weise, wie es verschiedene Datenbanktabellenbeziehungen zusammenfasst. Standardmäßig wählt CakePHP automatisch alle zugehörigen 'Gehört zu'-, 'Has One'- und 'Has Many'-Daten aus, was zu sehr großen SQL-Abfragen führen kann. Diese Abfragen sind bei der anfänglichen Entwicklung einer Anwendung möglicherweise kein Problem, aber nach sechs Monaten des Sammelns von Live-Daten stellen Sie möglicherweise fest, dass die Anwendung sehr langsam wird und in einigen Fällen abstürzt, wenn die Abfragen nicht optimiert sind.

Ich achte auf zwei Dinge, wenn ich eine bestehende Website auditiere. Erstens, wurde die standardmäßige rekursive Ebene geändert? Standardmäßig setzt CakePHP das rekursive Level auf 1, was meiner Meinung nach zu hoch ist. Ich setze es immer auf -1 und verwende dann das Containable-Verhalten, um alle zugehörigen Modelle abzurufen.

Das führt zu der zweiten Sache, nach der ich suche – wurde das Containable-Verhalten verwendet? Ich habe oft neue Kunden, die zu mir kommen und sagen, dass CakePHP langsam ist. Der Grund liegt fast immer darin, dass Containable nicht verwendet wurde! Ein guter CakePHP-Programmierer wird seine SQL-Abfragen optimieren, unabhängig davon, wie viel „automatische Magie“ hinter den Kulissen betrieben wird.

Das Containable-Verhalten wurde erst mit CakePHP 1.2 hinzugefügt, aber Junge, hat es einen Unterschied gemacht?! Stellen Sie sicher, dass Sie so viel wie möglich Containable verwenden, da dies eine so effektive Möglichkeit ist, Ihr SQL zu optimieren. Klicken Sie hier, um weitere Informationen zur Implementierung und Verwendung des Containable-Verhaltens zu erhalten.

Häufiger Fehler Nr. 3: Behalten Sie die Geschäftslogik in Controllern statt in Modellen

Guter CakePHP-Code hat die Logik in den Modelldateien. Das ist etwas gewöhnungsbedürftig, aber einmal gemeistert gibt es kein Zurück mehr! Eine Controller-Datei sollte für das verwendet werden, wofür sie im MVC-Muster vorgesehen ist – Steuern! Verwenden Sie also Ihre Controller-Datei, um Benutzeraktionen zu verarbeiten, während Sie die Geschäftslogik in die Modelldatei übertragen.

Ein gutes Beispiel dafür wäre ein einfaches CRUD – eine alltägliche Aktion! Nehmen wir als Beispiel die Funktion zum Hinzufügen von Beiträgen aus einem Blog-Tutorial. Die standardmäßige Add-Funktion lautet wie folgt:

 public function add() { if ($this->request->is('post')) { $this->Post->create(); if ($this->Post->save($this->request->data)) { $this->Session->setFlash(__('Your post has been saved.')); return $this->redirect(array('action' => 'index')); } $this->Session->setFlash(__('Unable to add your post.')); } }

Diese Controller-Aktion ist für ein einfaches Hinzufügen in Ordnung, aber was würde passieren, wenn Sie beispielsweise eine E-Mail an den Administrator senden möchten, wenn ein Beitrag hinzugefügt wird, oder eine andere Modellzuordnung aktualisieren, wenn ein Beitrag hinzugefügt wird? Dies ist zusätzliche Logik, aber diese Logik sollte nicht in unsere Controller-Datei aufgenommen werden.

Stattdessen würden wir eine Funktion dafür in unser Post.php Modell schreiben. Vielleicht so etwas:

 public function addPost($data = array(), $emailAdmin = true) { $this->create(); $this->save($data); // update any other tables // send the email to the admin user if ($emailAdmin) { } // if all is successful return true; }

Dies würde dann zu einer kleinen Änderung der Controller-Aktion wie folgt führen:

 public function add() { if ($this->request->is('post')) { if ($this->Post->addPost($this->request->data)) { $this->Session->setFlash(__('Your post has been saved.')); return $this->redirect(array('action' => 'index')); } $this->Session->setFlash(__('Unable to add your post.')); } }

Wie Sie sehen können, ist die neue Aktion tatsächlich eine Zeile weniger, da $this->Post->create() in die Modelldatei verschoben wurde.

Dies ist ein perfektes, alltägliches Beispiel dafür, wo das Verschieben von Logik in die Modelldatei eine gute Idee ist – und es sorgt sicherlich für eine viel sauberere Codebasis!

Häufiger Fehler Nr. 4: Dem Code zu viel Komplexität hinzufügen, anstatt oft und früh zurückzukehren

Dies ist immer eine etwas andauernde Debatte, aber häufiges Zurückkehren und frühes Zurückkehren sorgt sicherlich für viel sauberer aussehenden Code. Dies gilt vor allem für die Modellmethoden.

Aber was genau meine ich? Schauen wir uns die Methode an, die wir oben im CakePHP-Tutorial hinzugefügt haben:

 public function addPost($data = array(), $emailAdmin = true) { $this->create(); $this->save($data); // update any other tables // send the email to the admin user if ($emailAdmin) { } // if all is successful return true; }

Häufig und früh zurückzukehren bedeutet, dass wir während unserer Arbeit regelmäßig überprüfen, ob alles in Ordnung ist. Ist dies nicht der Fall, geben wir false oder einen CakePHP-Fehler zurück.

Am einfachsten lässt sich dies vielleicht an einem Beispiel zeigen. Es gibt zwei Möglichkeiten, die obige Funktion zu schreiben:

 public function addPost($data = array(), $emailAdmin = true) { if ($data) { $this->create(); $result = $this->save($data); if ($result) { // update any other tables // send the email to the admin user if ($emailAdmin) { // send the admin email } } else { // problem saving the data return false; } // if all is successful return true; } else { // no data submitted return false; } }

Sehen Sie, wie der Code schnell unlesbar wird? Es gibt else if und die Funktion wird schnell zu einer großen Einrückung. Verstehen Sie mich nicht falsch, ich liebe saubere Einrückungen, aber beobachten Sie, wie die Funktion aussieht, wenn sie mit dem Prinzip return oft, return early geschrieben wird.

 public function addPost($data = array(), $emailAdmin = true) { if (!$data) { // no data submitted return false; } $this->create(); $result = $this->save($data); if (!$result) { // problem saving the data return false; } // update any other tables // send the email to the admin user if ($emailAdmin) { // send the admin email } // if all is successful return true; }

In diesem kleinen Beispiel können Sie sofort sehen, dass der Code nur eine einzige Einrückung hat und viel besser lesbar ist. Die Logik ist eigentlich sinnvoller - lassen Sie die Logik Zeile für Zeile durchlaufen, und wenn es unterwegs zu Problemen kommt, geben Sie den Fehler zurück und fahren Sie nicht mit der nächsten Zeile fort.

Dadurch kann ein CakePHP-Programmierer genauso schreiben, wie wir lesen – Code von links nach rechts und von oben nach unten lesen, anstatt in verschiedenen Blöcken, was schnell verwirrend werden kann!

Häufiger Fehler Nr. 5: Das DRY-Prinzip nicht anwenden

DRY steht für Don't Repeat Yourself und ist eine Philosophie, die beim Codieren in CakePHP befolgt werden sollte. Bei objektorientiertem Code gibt es keine Entschuldigung dafür, denselben Codeblock zweimal zu wiederholen!

Hier sind einige CakePHP-Tipps, um sicherzustellen, dass Sie sich nicht wiederholen:

• Versuchen Sie, wie oben erwähnt, Logik in Modelldateien einzufügen, damit Sie die Logik gemeinsam nutzen können.

• Wenn Sie Ansichten wiederholen, erstellen Sie in Ihren Ansichtsdateien den Ansichtscode als Element oder sogar als benutzerdefinierten Helfer.

• Richten Sie einige Konfigurationseinstellungen ein – die Datei app/Config/bootstrap.php ist ein großartiger Ort dafür. Dadurch wird sichergestellt, dass Sie Dinge wie den Anwendungsnamen und die Haupt-E-Mail-Adresse nicht fest codieren. Das Letzte, was Sie tun möchten, ist, Hunderte von Dateien zu durchsuchen, nur weil der Client darum gebeten hat, eine E-Mail-Adresse in einer Anwendung zu aktualisieren.

• Fragen Sie sich immer: „Wenn ich Code wiederhole, gibt es einen besseren Weg, diesen Code zu schreiben, und füge ich diesen Code an der richtigen Stelle ein?“ Die Chancen stehen gut, wenn Sie Code wiederholen müssen, könnte er besser geschrieben werden.

Häufiger Fehler Nr. 6: Den Code nicht kommentieren

Der letzte Punkt, den ich ansprechen werde, bezieht sich auf Kommentare. Erstens, Doc-Blockierung. Ein Dokumentblock ist, wenn Sie eine Methode oder eine Aktion dokumentieren. Es dauert nur eine Minute, um ein wenig darüber aufzuzeichnen, was eine Funktion tut, aber es macht einen großen Unterschied in Bezug auf die Lesbarkeit des Codes.

CakePHP Doc Blocks müssen gegen den linken Rand der Seite gehen. Also ein einfaches Beispiel mit dem Code von oben.

 /** * Adds & saves a post as well as emails the admin to let them know the post has been added. * Also performs some saving to another table * * @param array $data The post data * @param bool $emailAdmin If set to true, will email the website admin * @return bool Returns true if successful */ public function addPost($data = array(), $emailAdmin = true) {

Wie Sie sehen werden, dauert es nicht lange, einen Dokumentblock zu schreiben, aber es macht einen großen Unterschied in Bezug auf die Langlebigkeit des Codes. Letztendlich bedeutet dies, dass der Code an Ihnen als Entwickler vorbei weiterleben kann.

Ebenso bei Inline-Kommentaren. Scheuen Sie sich nicht, zu erklären, was Ihr Code tut und warum! Es macht es auf lange Sicht viel einfacher, Ihren Code zu verstehen, besonders wenn ein anderer Entwickler ihn sich ansieht!

Einpacken

CakePHP ist ein umfangreiches Framework mit vollem Funktionsumfang. Da es der Konvention über die Konfiguration folgt, ist CakePHP strenger als andere PHP-basierte Frameworks, in dem Sinne, dass ein Benutzer „gezwungen“ wird, einer bestimmten Art der Gestaltung des Codes zu folgen. Dies kann kontrovers sein, aber meiner Erfahrung nach führt es zu einer konsistenteren, lesbareren und verständlicheren Codebasis - anstatt einen Entwickler „wählen“ zu lassen, wie der Code geschrieben werden soll, wird ein Entwicklungsteam konsistenten Code schreiben, indem es den Konventionen von Cake folgt .

Indem Sie diesem CakePHP-Tutorial folgen und sicherstellen, dass Ihr Code gut geschrieben ist, können Anwendungen den Test der Zeit bestehen. Code sollte immer für morgen geschrieben werden – damit ein anderer Entwickler, wenn er sich Jahre später einen bestimmten Codeblock ansieht, den Code versteht und sich an die erwarteten Standards hält. CakePHP ist nicht anders und hoffentlich hilft dieser Leitfaden dabei, einige schlechte Angewohnheiten zu korrigieren.