Rangka Kerja PHP: ralat tersembunyi untuk dielakkan

Kerangka seperti Symfony (7.2 pada masa penulisan) atau Laravel sangat boleh disesuaikan dan menggalakkan amalan baik, tanpa mengira pengalaman dan kemahiran anda.

Walau bagaimanapun, anda masih boleh memperkenalkan isu reka bentuk, keselamatan atau prestasi.

Symfony: jangan panggil $container secara langsung

❌ Yang ini adalah klasik tetapi masih banyak digunakan oleh pembangun:

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

Ia mungkin kerana induk AbstractController mentakrifkan $container sebagai dilindungi:

protected ContainerInterface $container;

Sumber: Symfony - GitHub

Walaupun ia berfungsi, ia adalah amalan yang buruk kerana pelbagai sebab:

• ia merosakkan kebolehbacaan
• lebih sukar untuk diuji
• ia bergantung pada keadaan global ($bekas)
• ia boleh membawa kepada isu ketidakserasian pada masa hadapan, kerana Symfony berkembang

✅ Gunakan suntikan kebergantungan dalam pembina sebaliknya:

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

ORM yang fasih: jangan gunakan pertanyaan mentah secara membuta tuli

Eloquent membolehkan menulis pertanyaan SQL dengan agak mudah.

Daripada menulis pertanyaan SQL secara langsung, pembangun boleh menggunakan pembalut PHP untuk berinteraksi dengan entiti pangkalan data.

Ia juga menggunakan pengikatan SQL di belakang tabir, jadi anda mendapat perlindungan suntikan secara percuma, walaupun dengan input yang tidak dipercayai:

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

❌ Walau bagaimanapun, apabila anda menggunakan pembantu seperti whereRaw, anda mungkin memperkenalkan kelemahan:

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

✅ Sekurang-kurangnya, sentiasa gunakan pengikatan SQL:

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

N.B.: contoh di atas tidak masuk akal, tetapi ia menjadikan perkara mudah. Dalam kes penggunaan dunia sebenar, anda mungkin memerlukan whereRaw untuk tujuan pengoptimuman atau untuk melaksanakan keadaan yang sangat spesifik.

Laravel: bagaimana dengan CSRF?

Dengan serangan CSRF, penggodam memaksa pengguna akhir untuk melaksanakan tindakan yang tidak diingini pada apl yang mana mereka sedang disahkan.

Laravel mempunyai mekanisme terbina dalam untuk melindungi daripada senario sedemikian.

Secara kasarnya, ia menambahkan token (medan tersembunyi) untuk dihantar bersama permintaan anda, jadi anda boleh mengesahkan bahawa "pengguna yang disahkan ialah orang yang sebenarnya membuat permintaan kepada aplikasi."

Cukup adil.

❌ Walau bagaimanapun, sesetengah apl melangkau pelaksanaan ini.

✅ Sama ada anda perlu menggunakan perisian tengah terbina dalam tidak berkaitan di sini, tetapi pastikan apl anda dilindungi daripada serangan CSRF.

Anda boleh membaca halaman ini untuk mendapatkan butiran lanjut tentang pelaksanaan dalam Laravel.

Sila selamatkan permintaan AJAX juga.

ORM fasih: pertanyaan tidak dioptimumkan "secara automatik"

Eloquent membenarkan pemuatan yang bersemangat/malas dan menyokong pelbagai pengoptimuman, seperti caching pertanyaan, pengindeksan atau pemprosesan kelompok.

Walau bagaimanapun, ia tidak menghalang semua isu prestasi, terutamanya pada set data yang besar.

❌ Selalunya melihat gelung sedemikian:

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

Tetapi ia boleh membawa kepada masalah ingatan.

✅ Jika boleh, pendekatan yang lebih baik akan memanfaatkan koleksi dan pembantu Laravel seperti bongkah:

protected ContainerInterface $container;

Semak dokumentasi untuk mendapatkan butiran lanjut.

N.B.: Ia berfungsi, tetapi jangan lupa pembantu itu hanya bertujuan untuk memudahkan pelaksanaan, jadi anda perlu memantau pertanyaan perlahan dan kesesakan lain.

Symfony: perkhidmatan SRP

Seperti yang dinyatakan dalam dokumentasi:

objek berguna dipanggil perkhidmatan dan setiap perkhidmatan tinggal di dalam objek yang sangat istimewa yang dipanggil bekas perkhidmatan. Bekas itu membolehkan anda memusatkan cara objek dibina. Ia menjadikan hidup anda lebih mudah, menggalakkan seni bina yang kukuh dan sangat pantas!

Dalam erti kata lain, anda akan menulis perkhidmatan tersuai untuk mengendalikan tanggungjawab khusus untuk permohonan anda.

❌ Dokumentasinya betul. Ia bertujuan untuk mempromosikan seni bina yang kukuh, tetapi tidak jarang membaca perkhidmatan yang melanggar Prinsip Tanggungjawab Tunggal (SRP):

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

✅ Anda mesti menghormati prinsip itu. Ia akan menjadi lebih mudah untuk menguji dan menyelenggara.

Symfony: perkhidmatan awam lwn swasta

❌ Dengan Symfony, anda boleh menggunakan $container->get('service_id') untuk menghubungi mana-mana perkhidmatan awam.

Kami melihat sebelum ini bahawa memanggil $container seperti itu dianggap sebagai satu amalan yang tidak baik.

Anda mungkin tidak dapat menahan godaan untuk membuat semua perkhidmatan awam, jadi anda boleh mendapatkannya dengan ID mereka hampir di mana-mana dalam projek.

Jangan buat begitu.

✅ Sebaliknya, pastikan kebanyakan perkhidmatan tersuai peribadi dan gunakan suntikan pergantungan.

Bungkus

Mudah-mudahan, anda akan mengelakkan perkara yang saya suka panggil "ralat terpendam" atau "ralat tersembunyi" dengan rangka kerja.

Jika anda tidak tahu cara melaksanakannya, percayai rangka kerja, tetapi maklum bahawa sesetengah mekanisme mungkin tidak didayakan secara lalai.

Atas ialah kandungan terperinci Rangka Kerja PHP: ralat tersembunyi untuk dielakkan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!