Modell
Wenn unsere Anwendung wächst, werden wir bald feststellen, dass wir ähnliche Datenbankoperationen an verschiedenen Stellen und in verschiedenen Präsentatoren durchführen müssen, um beispielsweise die neuesten veröffentlichten Artikel zu erfassen. Wenn wir unsere Anwendung verbessern, indem wir den Artikeln eine Markierung hinzufügen, die den Status „in Arbeit“ anzeigt, müssen wir auch alle Standorte in unserer Anwendung durchgehen und eine Where-Klausel hinzufügen, um sicherzustellen, dass nur fertige Artikel ausgewählt werden.
An diesem Punkt wird die direkte Arbeit mit der Datenbank unzureichend, und es wird klüger sein, uns mit einer neuen Funktion zu helfen, die veröffentlichte Artikel zurückgibt. Und wenn wir später eine weitere Klausel hinzufügen (z. B. um keine Artikel mit einem zukünftigen Datum anzuzeigen), müssen wir unseren Code nur an einer Stelle bearbeiten.
Wir platzieren die Funktion in der Klasse PostFacade
und nennen sie getPublicArticles()
.
Wir erstellen unsere Modellklasse PostFacade
im Verzeichnis app/Model/
, die sich um unsere Artikel
kümmert:
<?php
namespace App\Model;
use Nette;
final class PostFacade
{
public function __construct(
private Nette\Database\Explorer $database,
) {
}
public function getPublicArticles()
{
return $this->database
->table('posts')
->where('created_at < ', new \DateTime)
->order('created_at DESC');
}
}
In der Klasse übergeben wir die Datenbank Explorer. Damit nutzen wir die Leistungsfähigkeit des DI-Containers.
Wir werden zu HomePresenter
wechseln, das wir so bearbeiten, dass wir die Abhängigkeit von
Nette\Database\Explorer
loswerden und durch eine neue Abhängigkeit von unserer neuen Klasse ersetzen.
<?php
namespace App\UI\Home;
use App\Model\PostFacade;
use Nette;
final class HomePresenter extends Nette\Application\UI\Presenter
{
public function __construct(
private PostFacade $facade,
) {
}
public function renderDefault(): void
{
$this->template->posts = $this->facade
->getPublicArticles()
->limit(5);
}
}
Im Abschnitt use verwenden wir App\Model\PostFacade
, so dass wir den PHP-Code auf PostFacade
verkürzen können. Wir fordern dieses Objekt im Konstruktor an, schreiben es in die Eigenschaft $facade
und
verwenden es in der Methode renderDefault.
Der letzte verbleibende Schritt besteht darin, dem DI-Container beizubringen, dieses Objekt zu erzeugen. Dies geschieht in der
Regel durch Hinzufügen eines Aufzählungspunkts in der Datei config/services.neon
im Abschnitt
services
, in dem der vollständige Klassenname und die Konstruktorparameter angegeben werden. Dadurch wird es
sozusagen registriert, und das Objekt wird dann service genannt. Dank eines Zaubers namens Autowiring müssen wir die Konstruktorparameter normalerweise nicht angeben, da DI
sie erkennt und automatisch übergibt. Es würde also ausreichen, nur den Namen der Klasse anzugeben:
...
services:
- App\Model\PostFacade
Sie brauchen diese Zeile jedoch auch nicht hinzuzufügen. Im Abschnitt search
am Anfang von
services.neon
ist festgelegt, dass alle Klassen, die auf -Facade
oder -Factory
enden,
automatisch von DI nachgeschlagen werden, was auch für PostFacade
gilt.
Zusammenfassung
Die Klasse PostFacade
fragt in einem Konstruktor nach Nette\Database\Explorer
und da diese Klasse im
DI-Container registriert ist, erzeugt der Container diese Instanz und übergibt sie. DI erzeugt auf diese Weise eine
PostFacade
Instanz für uns und übergibt sie in einem Konstruktor an die HomePresenter Klasse, die danach gefragt
hat. Eine Art Matrjoschka-Puppe des Codes :) Alle Komponenten fordern nur an, was sie brauchen, und es ist ihnen egal, wo und wie
es erstellt wird. Die Erstellung wird vom DI-Container übernommen.
Hier können Sie mehr über Dependency Injection und über die Konfiguration lesen.