Kandungan
Tanyakan kepada saya kerangka mana yang harus digunakan dan saya mungkin akan mempunyai masa tua wanita yang pemarah dan memberitahu anda bahawa semua kerangka kerja sama buruknya antara satu sama lain. Yang tidak boleh dikatakan semuanya buruk, tetapi dalam PHP kita mempunyai sebilangan besar kerangka kerja yang tidak dapat dibayangkan (biasanya disebut sebagai N + 1, di mana N adalah bilangan pemaju PHP di dunia), dan semuanya mungkin masuk akal kepada orang yang mencipta mereka.
Mempunyai pilihan kerangka kerja mungkin lebih baik daripada mencuba hanya menggunakan satu kerangka kerja, tanpa mengira apa sebenarnya yang anda ingin bina, kerana ini adalah yang terbaik "(dengan ukuran apa pun" terbaik "). Pemilihan rangka kerja ini bermaksud bahawa anda dapat memilih sesuatu yang memenuhi keperluan projek dan mungkin juga didokumentasikan. Kerangka kerja di mana-mana platform benar-benar ada untuk menyediakan struktur, modul dan perpustakaan yang boleh digunakan semula, dan secara amnya mengelakkan semua tugas yang membosankan dan berulang-ulang dengan membina fungsi yang sama berulang-ulang. Contohnya semasa membina CMSes, sesuatu harus memproses dan mengesahkan bidang borang untuk saya; jika diserahkan kepada peranti saya sendiri, saya mungkin akan kehilangan sesuatu yang penting dan lebih baik saya memilih elemen setiap projek yang ada berbeza, bukannya yang sama setiap masa!
Rangka kerja timbunan penuh
Rangka kerja timbunan penuh, seperti Zend Framework, boleh menjadi tempat yang baik untuk memulakan pembangun tanpa banyak pengalaman seni bina. Ini memberikan struktur yang baik untuk menggantung aplikasi baru, dan ada 'ekosistem' yang bagus di sekitarnya - banyak buku, tutorial, dan beberapa dokumentasi yang masuk akal juga. Sekiranya anda ingin membina aplikasi besar yang akan dikendalikan oleh banyak orang, maka kerangka kerja yang komprehensif dan popular mungkin menjadi pilihan yang baik kerana ia akan menentukan struktur yang cukup banyak dan terkenal dan difahami.
Mempunyai struktur untuk membantu pemisahan selalu baik; pada awal kerjaya saya bekerja dengan beberapa orang sangat pemaju junior dan berusaha mengajar mereka corak MVC (Model View Controller), yang agak baru pada masa itu. Kami membuat keputusan untuk menggunakan Smarty di lapisan pandangan; sebahagiannya supaya pereka dapat bekerja dengan templat dengan lebih mudah, dan sebahagiannya sehingga ketika seseorang datang ke meja saya dan berkata "bagaimana saya melakukan X dengan Smarty?" Saya boleh mengatakan "jangan lakukan X dalam pandangan!" (sembilan daripada 10, itulah jawapannya). Mempunyai kerangka kerja membantu kita mencari pemisahan yang sama di bahagian lain aplikasi kita. Ramai di antara mereka menyokong penyatuan terhadap lapisan templat seperti Smarty, atau kegemaran baru saya, Twig, jadi anda boleh membawa alat-alat itu dengan kerangka yang anda pilih.
Ringankan beban
Terdapat banyak kerangka yang lebih ringan daripada Zend Framework, contohnya saya bekerjasama dengan CodeIgniter. Adakah sama komprehensif dan kukuh seperti Zend Framework? Tidak, tidak. Tetapi sebagai rangka kerja pembantu untuk membuat aplikasi dengan cepat, ia berguna. Secara amnya, kerangka kerja dengan fungsi yang lebih sedikit "penolong" lebih senang dicari kerana lebih jelas bagaimana kepingannya bersatu. Dalam kerangka yang tidak dikenali (bagi saya, itu hampir semuanya), bit automatik inilah yang menyukarkan kerja dan debug.
Perasaan "tersesat dalam kerangka baru" tidak dapat dielakkan dan sangat mengecewakan; malah pembangun yang berpengalaman terasa seperti pemula apabila mereka tidak tahu bagaimana sesuatu berfungsi. Sekiranya anda benar-benar tidak bernasib baik, anda akan memilih kerangka yang saluran IRC akan memberitahu anda bahawa anda juga orang bodoh! Pengalaman awal yang sangat negatif inilah yang membuat banyak orang tidak menggunakan kerangka kerja baru atau menerapkannya terlebih dahulu, dan sangat sedikit kerangka kerja yang baik untuk membantu pengguna baru mengatasi halangan awal itu.
Di PHP, kami juga mempunyai beberapa kerangka kerja yang sebenarnya bukan kerangka kerja seperti biasanya saya menggunakan perkataan. Kami mempunyai beberapa kerangka kerja komponen yang indah; koleksi perpustakaan yang dirancang untuk digunakan sesuka hati dan bermain dengan baik, seperti Zeta Components (sebelumnya eZ Components) dan Symfony Components (adakah anda pernah melihat laman web mereka? Mereka memenangi anugerah untuk karya seni terbaik!). Yang terbaik dan paling rendah dari ini, tentu saja, persembahan PEAR dan PECL PHP sendiri - entah bagaimana ini dilupakan dalam dunia kerangka baru yang berani ini.
Kerangka mikro
Kerangka mikro adalah trend yang muncul dalam PHP; ini adalah persembahan ringan yang hanya membantu anda merekatkan sesuatu dengan lebih cepat. Contoh yang baik ialah Slim, yang sangat cepat dan mudah digunakan, dan memahami konsep RESTful. Ini berdasarkan idea ‘laluan’, yang merupakan corak URL. Anda mendaftarkan laluan dan memberikan panggilan balik yang harus dipanggil ketika URL tersebut diminta.
Sebilangan besar pemaju PHP menggunakan kerangka kerja dan tetap menggunakannya, atau mereka mungkin menggunakan satu di tempat kerja dan yang lain untuk hobi atau projek sumber terbuka mereka. Terdapat sedikit kata sepakat mengenai kerangka "terbaik" untuk digunakan sehingga semua orang hanya berpegang pada apa yang mereka ketahui dan hasilnya adalah pengembangan selari sejumlah besar kerangka kerja! Saya suka mempunyai pilihan untuk dipilih, tetapi adakah saya menyebut bahawa semuanya sama buruknya antara satu sama lain?
Sekiranya anda mengetahui Zend Framework maka anda akhirnya menggambarkan diri anda sebagai pembangun Zend Framework; anda tidak akan selesa menulis dalam kerangka lain sehingga anda berpeluang untuk mengatasinya, dan anda mungkin tidak ingat banyak fungsi PHP mentah untuk perkara jika anda tidak menggunakannya secara kerap. Idea ini bahawa kami telah menjadi pembangun khusus rangka kerja, hanya bekerja di atas lapisan abstraksi, agak pelik bagi PHP. Lagipun, ini adalah bahasa "untuk menyelesaikan masalah web". Ia ditulis dalam bahasa C dan merupakan bahasa yang cepat dan ringan ... dengan syarat anda tidak menunggu proses bootstrap rangka kerja besar! Dari konteks ini muncul Manifesto MicroPHP, yang ditulis oleh seorang lelaki yang kita panggil Funkatron (walaupun namanya benar-benar Ed Finkler). Ini adalah satu siri pernyataan yang mengatakan bahawa tidak apa-apa untuk membina sejumlah modul kecil yang tidak dapat dikendalikan, yang lebih besar tidak lebih baik, dan sebenarnya, hidup terlalu pendek untuk Java - walaupun ditulis dalam PHP.
