PHP-Frameworks: versteckte Fehler, die es zu vermeiden gilt

Frameworks wie Symfony (7.2 zum Zeitpunkt des Schreibens) oder Laravel sind hochgradig anpassbar und fördern gute Praktiken, unabhängig von Ihrer Erfahrung und Ihren Fähigkeiten.

Es können jedoch weiterhin Design-, Sicherheits- oder Leistungsprobleme auftreten.

Symfony: Rufen Sie den $container nicht direkt auf

❌ Dies ist ein Klassiker, wird aber immer noch häufig von Entwicklern verwendet:

 class LuckyController extends AbstractController
  {
      public function index()
       {
        $myDependency = $this->container->get(MyDependencyInterface::class);
        // 
       }

Das ist möglich, weil der übergeordnete AbstractController $container als geschützt definiert:

protected ContainerInterface $container;

Quelle: Symfony – GitHub

Obwohl es funktioniert, ist es aus verschiedenen Gründen eine schlechte Praxis:

• es beeinträchtigt die Lesbarkeit
• es ist schwieriger zu testen
• es basiert auf globalen Zuständen ($container)
• Es könnte in Zukunft zu Inkompatibilitätsproblemen führen, wenn sich Symfony weiterentwickelt

✅ Verwenden Sie stattdessen die Abhängigkeitsinjektion im Konstruktor:

 class LuckyController extends AbstractController
  {
      public function __construct(private MyDependencyInterface $myDependency) {}

Eloquentes ORM: Verwenden Sie Rohabfragen nicht blind

Eloquent ermöglicht das ganz bequeme Schreiben von SQL-Abfragen.

Anstatt SQL-Abfragen direkt zu schreiben, können Entwickler PHP-Wrapper verwenden, um mit Datenbankentitäten zu interagieren.

Es verwendet auch SQL-Bindungen im Hintergrund, sodass Sie auch bei nicht vertrauenswürdigen Eingaben kostenlosen Injektionsschutz erhalten:

User::where('email', $request->input('email'))->get();

❌ Wenn Sie jedoch Hilfsprogramme wie whereRaw verwenden, können Sicherheitslücken entstehen:

User::whereRaw('email = "'. $request->input('email'). '"')->get();

✅ Zumindest immer SQL-Bindungen verwenden:

User::whereRaw('email = :email', ['email' => $request->input('email')])->get();

Hinweis: Das obige Beispiel ergibt keinen Sinn, aber es hält die Dinge einfach. In realen Anwendungsfällen benötigen Sie whereRaw möglicherweise zu Optimierungszwecken oder zur Implementierung sehr spezifischer Where-Bedingungen.

Laravel: Was ist mit CSRF?

Mit CSRF-Angriffen zwingen Hacker die Endbenutzer dazu, unerwünschte Aktionen in einer App auszuführen, in der sie derzeit authentifiziert sind.

Laravel verfügt über einen integrierten Mechanismus zum Schutz vor solchen Szenarios.

Grob gesagt wird ein Token (verborgenes Feld) hinzugefügt, das zusammen mit Ihren Anfragen gesendet wird, sodass Sie überprüfen können, ob „der authentifizierte Benutzer die Person ist, die tatsächlich die Anfragen an die Anwendung stellt.“

In Ordnung.

❌ Einige Apps überspringen diese Implementierung jedoch.

✅ Ob Sie die integrierte Middleware verwenden sollten, ist hier nicht relevant, aber stellen Sie sicher, dass Ihre App vor CSRF-Angriffen geschützt ist.

Weitere Informationen zur Implementierung in Laravel finden Sie auf dieser Seite.

Bitte sichern Sie auch AJAX-Anfragen.

Eloquentes ORM: Abfragen werden nicht „automatisch“ optimiert

Eloquent ermöglicht Eager/Lazy Loading und unterstützt verschiedene Optimierungen, wie etwa Abfrage-Caching, Indizierung oder Stapelverarbeitung.

Es verhindert jedoch nicht alle Leistungsprobleme, insbesondere bei großen Datenmengen.

❌ Es ist nicht ungewöhnlich, solche Schleifen zu sehen:

 class LuckyController extends AbstractController
  {
      public function index()
       {
        $myDependency = $this->container->get(MyDependencyInterface::class);
        // 
       }

Aber es kann zu Gedächtnisproblemen führen.

✅ Wenn möglich, wäre ein besserer Ansatz die Nutzung von Laravel-Sammlungen und Helfern wie chunk:

protected ContainerInterface $container;

Weitere Informationen finden Sie in der Dokumentation.

Hinweis: Es funktioniert, aber vergessen Sie nicht, dass diese Helfer nur die Implementierung erleichtern sollen, Sie müssen also langsame Abfragen und andere Engpässe überwachen.

Symfony: SRP-Dienste

Wie in der Dokumentation steht:

Nützliche Objekte werden Dienste genannt und jeder Dienst befindet sich in einem ganz besonderen Objekt, dem Dienstcontainer. Mit dem Container können Sie die Art und Weise, wie Objekte erstellt werden, zentralisieren. Es macht Ihr Leben einfacher, fördert eine starke Architektur und ist superschnell!

Mit anderen Worten, Sie schreiben benutzerdefinierte Dienste, um bestimmte Verantwortlichkeiten für Ihre Anwendung zu übernehmen.

❌ Die Dokumentation stimmt. Es zielt darauf ab, eine starke Architektur zu fördern, aber es ist nicht ungewöhnlich, Dienste zu lesen, die gegen das Single Responsibility Principle (SRP) verstoßen:

 class LuckyController extends AbstractController
  {
      public function __construct(private MyDependencyInterface $myDependency) {}

✅ Sie müssen diesen Grundsatz respektieren. Es wird einfacher zu testen und zu warten sein.

Symfony: öffentliche vs. private Dienste

❌ Mit Symfony können Sie $container->get('service_id') verwenden, um jeden öffentlichen Dienst aufzurufen.

Wir haben bereits gesehen, dass es als schlechte Praxis gilt, den $container so aufzurufen.

Sie können der Versuchung nicht widerstehen, alle Dienste öffentlich zu machen, sodass Sie sie fast überall im Projekt anhand ihrer ID abrufen können.

Tu das nicht.

✅ Halten Sie stattdessen die meisten benutzerdefinierten Dienste privat und verwenden Sie die Abhängigkeitsinjektion.

Einpacken

Hoffentlich vermeiden Sie das, was ich bei Frameworks gerne als „latente Fehler“ oder „versteckte Fehler“ bezeichne.

Wenn Sie nicht wissen, wie Sie es implementieren sollen, vertrauen Sie dem Framework. Beachten Sie jedoch, dass einige Mechanismen möglicherweise nicht standardmäßig aktiviert sind.

Das obige ist der detaillierte Inhalt vonPHP-Frameworks: versteckte Fehler, die es zu vermeiden gilt. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!