Isi
Tanyakan kepada saya kerangka kerja mana yang akan digunakan dan saya mungkin akan mengalami momen wanita tua yang pemarah dan memberi tahu Anda bahwa semua kerangka itu seburuk satu sama lain. Yang tidak berarti mereka semua buruk, tepatnya, tetapi di PHP kami memiliki sejumlah besar kerangka kerja yang tak terbayangkan (biasanya dikutip sebagai N + 1, di mana N adalah jumlah pengembang PHP di dunia), dan semuanya mungkin masuk akal kepada orang yang menciptakannya.
Memiliki pilihan kerangka kerja mungkin lebih baik daripada mencoba menggunakan hanya satu kerangka kerja, terlepas dari apa sebenarnya yang Anda coba buat, karena itu yang 'terbaik' (dengan ukuran apa pun yang 'terbaik'). Pilihan penawaran kerangka kerja ini berarti Anda dapat memilih sesuatu yang memenuhi kebutuhan proyek dan bahkan mungkin didokumentasikan. Kerangka kerja pada platform apa pun benar-benar ada untuk menyediakan struktur, modul dan pustaka yang dapat digunakan kembali, dan umumnya menghindari semua tugas yang membosankan dan berulang yang harus dilakukan dengan membangun fungsionalitas yang sama berulang kali. Misalnya ketika membangun CMS, sesuatu harus memproses dan memvalidasi bidang formulir untuk saya; jika dibiarkan sendiri, saya mungkin kehilangan sesuatu yang penting dan saya lebih suka mengerjakan elemen dari setiap proyek yang ada berbeda, daripada yang selalu sama!
Kerangka kerja tumpukan penuh
Kerangka kerja tumpukan penuh, seperti Zend Framework, bisa menjadi tempat yang bagus untuk memulai bagi pengembang yang tidak memiliki banyak pengalaman arsitektur. Ini memberikan struktur yang baik untuk memasang aplikasi baru, dan ada 'ekosistem' yang baik di sekitarnya - banyak buku, tutorial, dan beberapa dokumentasi yang masuk akal juga. Jika Anda mencoba membangun aplikasi besar yang akan dikelola oleh banyak orang, maka kerangka kerja yang populer dan komprehensif kemungkinan besar akan menjadi pilihan yang baik karena akan menentukan struktur yang cukup banyak dan dikenal serta dipahami dengan baik.
Memiliki struktur untuk membantu pemisahan selalu baik; di awal karir saya, saya bekerja dengan beberapa sangat pengembang junior dan berusaha untuk mengajari mereka pola MVC (Model View Controller), yang relatif baru pada saat itu. Kami membuat keputusan untuk menggunakan Smarty di lapisan tampilan; sebagian agar para desainer dapat bekerja dengan templat dengan lebih mudah, dan sebagian lagi agar ketika seseorang datang ke meja saya dan berkata "bagaimana cara melakukan X dengan Smarty?" Saya bisa berkata "jangan lakukan X dalam tampilan!" (sembilan dari 10, itulah jawabannya). Memiliki kerangka kerja membantu kami menemukan pemisahan yang sama di bagian lain aplikasi kami. Banyak dari mereka mendukung integrasi terhadap lapisan templating seperti Smarty, atau favorit baru saya, Twig, sehingga Anda dapat membawa alat tersebut bersama Anda kerangka mana pun yang Anda pilih.
Meringankan beban
Ada banyak framework yang lebih ringan dari Zend Framework, contohnya saya bekerja dengan CodeIgniter cukup banyak. Apakah itu selengkap dan sekuat Zend Framework? Tidak, tidak. Namun sebagai kerangka kerja pembantu untuk memungkinkan pembuatan aplikasi dengan cepat, ini berguna. Secara umum, kerangka kerja dengan lebih sedikit fungsi 'pembantu' dapat lebih mudah ditemukan karena jauh lebih jelas bagaimana bagian-bagian tersebut digabungkan. Dalam kerangka kerja yang tidak biasa (bagi saya, itu hampir semuanya), bit automagical-lah yang membuatnya sulit untuk dikerjakan dan di-debug.
Perasaan "tersesat dalam kerangka baru" tidak dapat dihindari dan sangat membuat frustrasi; bahkan pengembang yang berpengalaman pun akan merasa seperti pemula saat mereka tidak tahu cara kerja apa pun. Jika Anda benar-benar tidak beruntung, Anda akan memilih kerangka kerja yang saluran IRC-nya akan memberi tahu Anda bahwa Anda juga idiot! Pengalaman awal yang sangat negatif inilah yang membuat banyak orang tidak menggunakan framework baru atau mengadopsi framework baru, dan sangat sedikit framework yang berfungsi dengan baik dalam membantu pengguna baru mengatasi rintangan awal tersebut.
Di PHP kami juga memiliki beberapa kerangka kerja yang sebenarnya bukan kerangka kerja seperti yang biasa saya gunakan. Kami memiliki beberapa kerangka komponen yang bagus; koleksi perpustakaan yang dirancang untuk digunakan sesuka hati dan untuk bermain bersama dengan baik, seperti Komponen Zeta (sebelumnya Komponen eZ) dan Komponen Symfony (pernahkah Anda melihat situs mereka? Mereka memenangkan penghargaan untuk karya seni terbaik!). Yang terbaik dan paling penting dari ini adalah, tentu saja, penawaran PEAR dan PECL PHP sendiri - entah bagaimana ini terlupakan di dunia kerangka kerja baru yang berani ini.
Microframeworks
Microframeworks adalah tren yang muncul di PHP; ini adalah penawaran super ringan yang hanya membantu Anda merekatkan berbagai hal lebih cepat. Contoh yang bagus adalah Slim, yang sangat cepat dan mudah digunakan, serta memahami konsep RESTful. Ini didasarkan pada gagasan 'rute', yang merupakan pola URL. Anda mendaftarkan rute dan memberikan panggilan balik yang harus dipanggil saat URL itu diminta.
Sebagian besar pengembang PHP mengadopsi kerangka kerja dan tetap menggunakannya, atau mereka mungkin menggunakannya di tempat kerja dan yang lain untuk hobi atau proyek sumber terbuka mereka. Ada sedikit konsensus tentang kerangka kerja "terbaik" untuk digunakan sehingga semua orang hanya berpegang pada apa yang mereka ketahui dan hasilnya adalah pengembangan paralel dari sejumlah besar kerangka kerja! Saya suka memiliki pilihan untuk dipilih, tetapi apakah saya menyebutkan bahwa mereka semua sama buruknya satu sama lain?
Jika Anda tahu Zend Framework maka Anda akhirnya menggambarkan diri Anda sebagai pengembang Zend Framework; Anda tidak akan merasa nyaman menulis di framework lain sampai Anda memiliki kesempatan untuk menguasainya, dan Anda mungkin tidak ingat banyak fungsi PHP mentah untuk berbagai hal jika Anda tidak sering menggunakannya. Gagasan bahwa kami telah menjadi pengembang khusus kerangka kerja, yang hanya bekerja di atas lapisan abstraksi, agak aneh untuk PHP. Bagaimanapun, ini adalah bahasa "untuk memecahkan masalah web". Itu ditulis dalam C dan merupakan bahasa yang cepat dan ringan ... asalkan Anda tidak menunggu proses bootstrap kerangka kerja yang besar untuk dijalankan! Dari konteks inilah muncul Manifesto MicroPHP, yang ditulis oleh seseorang yang kita sebut Funkatron (walaupun namanya sebenarnya Ed Finkler). Ini adalah serangkaian pernyataan yang mengatakan bahwa tidak masalah untuk membangun sejumlah modul kecil yang dapat dioperasikan, yang lebih besar tidak lebih baik, dan itu sebenarnya, hidup terlalu singkat untuk Java - bahkan jika itu ditulis dalam PHP.
