PHP 框架：需要避免的隱藏錯誤

Symfony（撰寫本文時為 7.2）或 Laravel 等框架是高度可定制的，並且無論您的經驗和技能如何，都鼓勵良好的實踐。

但是，您仍然可能會引入設計、安全或效能問題。

Symfony：不要直接呼叫 $container

❌ 這是一個經典但仍被開發人員大量使用的：

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

這是可能的，因為父 AbstractController 將 $container 定義為 protected：

protected ContainerInterface $container;

來源：Symfony - GitHub

雖然它確實有效，但由於多種原因，這是一個不好的做法：

• 它會損害可讀性
• 測試更難
• 它依賴全域狀態（$container）
• 隨著 Symfony 的發展，它可能會在未來導致不相容問題

✅ 在建構函式中使用依賴注入：

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

Eloquent ORM：不要盲目使用原始查詢

Eloquent 允許非常方便地編寫 SQL 查詢。

開發人員可以使用 PHP 包裝器與資料庫實體交互，而不是直接編寫 SQL 查詢。

它還在後台使用 SQL 綁定，因此即使輸入不受信任，您也可以免費獲得注入保護：

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

❌但是，當您使用像 whereRaw 這樣的幫助程式時，您可能會引入漏洞：

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

✅ 至少，總是使用 SQL 綁定：

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

注意：上面的例子沒有意義，但它讓事情變得簡單。在現實世界的用例中，您可能需要 whereRaw 來進行最佳化或實作非常具體的 where 條件。

Laravel：CSRF 怎麼樣？

透過 CSRF 攻擊，駭客迫使最終用戶在他們目前經過身份驗證的應用程式上執行不必要的操作。

Laravel 有一個內建機制來防範這種情況。

粗略地說，它添加了一個與您的請求一起發送的令牌（隱藏欄位），因此您可以驗證「經過身份驗證的使用者是實際向應用程式發出請求的人。」

很公平。

❌但是，某些應用程式會跳過此實作。

✅ 是否應該使用內建中間件與此處無關，但請確保您的應用程式免受 CSRF 攻擊。

您可以閱讀此頁面以了解有關 Laravel 中實現的更多詳細資訊。

也請確保 AJAX 請求的安全性。

Eloquent ORM：查詢沒有「自動」優化

Eloquent 允許急切/延遲加載，並支援各種最佳化，例如查詢快取、索引或批次。

但是，它並不能防止所有效能問題，尤其是在大型資料集上。

❌ 這種循環並不罕見：

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

但它可能會導致記憶體問題。

✅ 如果可能，更好的方法是利用 Laravel 集合和區塊等幫助器：

protected ContainerInterface $container;

查看文件以了解更多詳細資訊。

注意：它有效，但不要忘記這些助手只是為了簡化實現，因此您必須監視緩慢的查詢和其他瓶頸。

Symfony：SRP 服務

如文件所述：

有用的物件稱為服務，每個服務都位於一個非常特殊的物件中，稱為服務容器。容器可讓您集中建構物件的方式。它讓您的生活更輕鬆，促進強大的架構並且速度超級快！

換句話說，您將編寫自訂服務來處理您的應用程式的特定職責。

❌文檔是正確的。它旨在促進強大的架構，但閱讀違反單一職責原則 (SRP) 的服務並不罕見：

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

✅ 你必須尊重這個原則。測試和維護會更容易。

Symfony：公共服務與私人服務

❌ 使用 Symfony，您可以使用 $container->get('service_id') 來呼叫任何公用服務。

我們之前看到，像這樣呼叫 $container 被認為是一種不好的做法。

您可能無法抗拒將所有服務公開的誘惑，因此您幾乎可以在專案中的任何地方透過它們的 ID 檢索它們。

不要這樣做。

✅ 相反，將大多數自訂服務保持私有並使用相依性注入。

包起來

希望您能夠避免我所說的框架的「潛在錯誤」或「隱藏錯誤」。

如果您不知道如何實現它，請相信該框架，但請注意某些機制可能在預設情況下未啟用。

以上是PHP 框架：需要避免的隱藏錯誤的詳細內容。更多資訊請關注PHP中文網其他相關文章！