Negeri Rangka Kerja PHP MVC pada tahun 2017

mata utama

Laravel dan Symfony kini mengetuai rangka kerja PHP MVC dengan komuniti yang kuat dan keupayaan baru untuk pembangunan yang berterusan.
Kebangkitan mikroservis dan seni bina berasaskan kontena mengubah peranan MVC untuk membina aplikasi sebagai "fungsi".
Walaupun Laravel berada di dalam memimpin, model fasih besar dan perkhidmatan yang berlebihan dapat merumitkannya, mengakibatkan aplikasi monolitik.
Symfony Walaupun kadang -kadang ia membawa kepada aplikasi monolitik, ia memberikan keanggunan dan fleksibiliti dengan menggunakan repositori.
Kemunculan mikroservis tidak bermakna bahawa PHP sedang mati, tetapi pemaju harus terus maju dan mempertimbangkan pembelajaran golang atau node.js.

Artikel ini pada asalnya diterbitkan pada Zenofcoding dan diterbitkan semula di sini dengan izin dari penulis.

---

Soalan mudah mendorong saya untuk duduk dan menulis susulan ini kepada jawatan saya kira-kira setahun yang lalu.

Q: Apa pendapat anda tentang keadaan semasa? (24 Februari 2017)

A: "Saya fikir ia terpulang kepada Laravel dan Symfony sekarang; sejauh Rangka Kerja PHP. Zend, Codeigniter, Yii, dll. Saya dapat melihat alasan untuk menggunakan rangka kerja ini hanya jika anda sudah tahu tentang mereka atau mempunyai pemaju yang mempunyai tabiat menggunakannya. Apabila pembangunan sebenar bermula, anda mesti dapat mencari jawapan kepada alat, plugin, dan soalan yang sering ditanya. Dengan komuniti Laravel dan Symfony dan perkembangan "modul" atau ciri -ciri baru yang berterusan, anda tidak pernah berasa mundur. Laracasts sahaja (walaupun anda tidak berkembang dengan Laravel) adalah hebat.

Sama ada integrasi dengan perkhidmatan seperti Iron.io atau penyedia SaaS lain, sokongan untuk pelbagai sumber data, atau persekitaran pembangunan tempatan seperti Homestead, rangka kerja dan modul sokongan ini lebih berpandangan ke hadapan.

Lumen melengkapkan pembangunan API yang cepat, dan Laravel adalah kaedah yang sangat baik untuk pembangunan aplikasi dan prototaip yang cepat hari ini. Ini bukan untuk mengatakan ia tertakluk kepada beberapa jenis batasan apabila membina aplikasi besar.

bagaimanapun, secara keseluruhan, kita melihat peralihan kepada seni bina berasaskan kontena di mana MVC kurang berkesan. Ini semua mengenai microservices, orkestra, dan aplikasi bangunan ke dalam "fungsi" (iaitu AWS Lambda dan perkhidmatan serupa). Mungkin sudah tiba masanya untuk meningkatkan kemahiran node.js dan golang anda :) "

Walaupun saya secara umumnya berpuas hati dengan jawapan ini, saya tidak dapat membantu tetapi fikir ia adalah idea yang baik untuk menghuraikan beberapa perkara ini dan mengkaji semula status quo.

Sebelum saya mula bercakap tentang topik aneh seperti "Golang", mari kita melangkah mundur dan lihat trend dalam bidang Rangka Kerja MVC PHP 2017.

Saya fikir trend yang telah kita perhatikan pada masa lalu berterusan. Laravel masih berkembang sementara yang lain berada di belakang. Populariti Symfony telah meningkat sedikit, mungkin disebabkan oleh pelepasan Symfony 3 yang sangat dinanti -nantikan.

(Saya mencuba carian perbandingan yang lebih spesifik seperti "CakePHP 3" atau "ZF2" tetapi carian ini tidak menghasilkan trend yang signifikan secara statistik).

Saya menyertai CodeIgniter tahun ini kerana ia sangat popular, dan itu jelas. Saya telah menerima banyak soalan mengenai CodeIgniter dan pendapat saya di tempatnya dalam komuniti PHP MVC ... Singkatnya, CI masih tidak bersaing kerana ia bukan rangka kerja MVC yang sebenar. Saya tidak tahu bagaimana memanggilnya kecuali koleksi popo yang teratur ...

mari kita kutip secara langsung dari manual mereka:

codeigniter mengambil pendekatan yang agak longgar ke MVC kerana tiada model diperlukan. Jika anda tidak memerlukan pemisahan tambahan, atau mendapati bahawa mengekalkan model lebih kompleks daripada yang anda inginkan, anda boleh mengabaikannya dan membina aplikasi anda dengan cara yang minimum menggunakan pengawal dan pandangan.

Saya benar -benar tidak bersetuju dengan pendekatan ini ketika membina kerangka kerja. Mungkin ia adalah boilerplate yang bagus, itulah sebabnya CodeIgniter popular, tetapi kerangka itu harus menguatkuasakan disiplin tertentu atau produk akhir akan menjadi sekumpulan kod spageti yang dibungkus dalam beberapa jenis "corak".

Seterusnya, Symfony 3 membawa kita beberapa penambahbaikan kepada pengalaman pemaju, suntikan pergantungan, dan banyak ciri lain. Seperti banyak rakan PHP, ia kini menyediakan microframework. Sebaliknya, ZF3 menawarkan pelbagai penambahbaikan, seperti sokongan untuk Php7 (akhirnya) dan juga microframeworknya sendiri ... tetapi sebagai manual mereka berkata:

Untuk Rangka Kerja Zend 2 Pengguna MVC, perbezaannya adalah halus ...

Saya sangat berharap mereka mengatakan terdapat banyak perbezaan, terdapat beberapa peningkatan seni bina utama, dan beberapa modul baru yang indah yang membantu anda mengembangkan perkara dengan cara yang moden. Malangnya, dalam kebanyakan kes, ZF3 masih sangat mirip dengan ZF2.

cerita panjang pendek

ini adalah bagaimana saya melihat dunia kerangka PHP hari ini:

1. Symfony atau Laravel, bergantung kepada keperluan anda
2. Lain -lain

Tidak ada keraguan bahawa Laravel mencuri pertunjukan. Jumlah maklumat yang ada, Laracasts, bakat pemaju global, pelaksanaan skema mudah, alat ujian bersepadu, pelaksanaan rekod aktiviti dalam bentuk fasih, versi ringan dalam lumen, pembangunan tempatan menggunakan homestead (vagrant) menjadikan rangka kerja ini untuk menonjol untuk kedua -dua pemula dan pemaju yang berpengalaman.

Tetapi model fasih boleh menjadi berantakan dan agak besar, berpotensi mewujudkan terlalu banyak perkhidmatan Laravel (tidak boleh dikelirukan dengan microservices), dan orang mula mempertimbangkan untuk melaksanakan corak repositori di mana ia tidak sesuai. Oleh itu, aplikasi monomer dilahirkan.

Jika anda tidak biasa dengan mod rekod aktif dan memerlukan fleksibiliti tambahan repositori, atau anda tidak suka melihat terlalu banyak fungsi tanpa nama, kemudian gunakan doktrin Symfony. Adakah saya fikir Symfony adalah jalan ke aplikasi monolitik? Untuk beberapa tahap, ya. Walau bagaimanapun, ia mungkin yang paling elegan.

Secara keseluruhan, saya tidak akan menyebutnya perubahan drastik berbanding tahun lepas. Namun, kita perlu melihat masalah dari perspektif yang lebih besar: aplikasi yang direka dengan baik bukan hanya MVC; Semua ini boleh dilaksanakan dalam timbunan MVC, tetapi penjagaan tambahan diperlukan untuk mengelakkan aplikasi monolitik.

kemunculan microservices

Saya menyebut kebangkitan microservices dan keperluan untuk meningkatkan kemahiran golang atau nod. Malah, walaupun dalam artikel PHP MVC, ia akan menjadi bodoh untuk tidak menyebutkan peralihan yang jelas kepada seni bina berorientasikan mikroservis (MOA);

Walaupun kedua -dua konsep ini tidak saling eksklusif, tidak ada sebab untuk cuba mencari persamaan antara kedua -dua, kerana mereka mewakili yang berbeza, walaupun falsafah yang bersilang.

Sebagai contoh, meletakkan aplikasi MVC anda dalam satu bekas, meletakkan MySQL dalam bekas lain, dan kemudian menghubungkannya bersama -sama tidak semestinya mewakili MOA yang sesuai. Ini sememangnya pendekatan yang lebih baik, sebenarnya, lebih baik daripada cuba memasang MAMP, XAMPP, atau apa sahaja perkara yang tidak baik yang anda perlukan untuk mendapatkan mesin tempatan untuk melayani permohonan anda.

Di samping itu, ia dapat menyelesaikan beberapa masalah seperti mudah menjalankan persekitaran tempatan pada platform yang berbeza (pemaju), dan menggunakan dasar dalam beberapa kes, tetapi aplikasi monolitik MVC masih wujud di lapisan/bekas aplikasi anda.

pemusnahan aplikasi monomer

jenis "kemusnahan" ini adalah apa yang ingin dicapai oleh microservices. Walaupun MVC menyelesaikan struktur kod dan isu organisasi anda dengan menyediakan cara yang boleh dipercayai untuk memisahkan kebimbangan, kontena/perkhidmatan/MOA memanjangkan konsep ini lebih jauh lagi.

Anda tidak lagi memisahkan pandangan dari model, tetapi kini memisahkan setiap "blok" atau unit logik aplikasi ke dalam perkhidmatan berasingan yang direka untuk mengendalikan tanggungjawabnya sendiri.

Jika aplikasi MVC anda mempunyai kaedah "carian", operasi, dan kaedah model yang berkaitan, maka kami sudah mempunyai contoh aplikasi monolitik.

Sebaliknya, menggunakan kaedah MOA, kami akan menyediakan satu perkhidmatan untuk setiap unit pemprosesan. Contohnya:

Perkhidmatan Routing

• Perkhidmatan Permintaan
• Perkhidmatan siasatan
• Perkhidmatan Sumber Data
• Perkhidmatan Respons
tunggu, tetapi bukan semua "perkhidmatan" ini sebahagian daripada timbunan MVC? Ya, itu sahaja. Mereka membina blok untuk aplikasi monolitik kami.

Dengan MOA, setiap perkhidmatan berjalan di persekitarannya sendiri, dan sebagai pemaju dan yang lebih penting, sebagai arkitek, kami bebas untuk merekabentuk cara terbaik untuk menyelesaikan keperluan khusus.

Sebagai contoh, jika saya menulis perkhidmatan pemprosesan imej dalam persekitaran Laravel, saya mungkin menggunakan alat seperti sambungan PHP-GD2, yang mungkin bukan cara yang paling berkesan untuk memproses imej. Perkhidmatan C yang mengendalikan keperluan pemprosesan imej saya mungkin lebih cepat dan pastinya lebih kuat pada skala. Untuk menghuraikan lebih lanjut, kami kini boleh mengambil output perkhidmatan pemprosesan imej dan menghantarnya ke perkhidmatan datastore, perkhidmatan CloudStorage, dan perkhidmatan e -mel giliran.

menggunakan sekumpulan pekerjaan cron dan mungkin beberapa aplikasi MVC yang berasingan dan skrip tersuai untuk menyelesaikan cabaran yang sama, itulah yang kami lakukan pada masa lalu (iaitu 2 tahun yang lalu). Sudah tiba masanya untuk bergerak ke hadapan.

Skalabiliti

Ini adalah di mana masalah bermula (atau berakhir, bergantung pada tempat anda menuju). Di satu pihak, sukar untuk skala aplikasi monolitik, dan jika anda membina lebih banyak logik dalam timbunan MVC yang sama, anda mungkin dapat melihat aplikasi berstruktur yang baik, tetapi kerumitannya menakutkan.

Sebaliknya, jika anda membina beribu -ribu microservices dalam bahasa yang berbeza, bagaimana anda menguruskan kekacauan itu?

Lebih daripada satu bencana telah dilaporkan.

Terdapat pelbagai alat orkestrasi kontena (seperti Kubernetes, Swarm, Mesos), perkhidmatan penempatan kontena (iaitu GKE dan AWS ECS), tetapi beberapa perusahaan telah menguasai seni bina Docker. Terdapat beberapa kisah kejayaan mengenai infrastruktur bangunan menggunakan Docker atau teknologi kontena lain (iaitu GKE). Kebanyakan kes ini datang dari syarikat yang boleh menjalankan sumber arkitek, DevOps, DBA dan jurutera. Walau bagaimanapun, buat masa ini, terdapat banyak perdebatan tentang cara menggunakan MOA yang diatur dan elegan. Dalam kes ini, satu saiz benar -benar tidak sesuai untuk semua situasi, dan terdapat banyak cara untuk menyelesaikan cabaran anda.

Sama ada, anda tidak dapat menyelesaikan masalah ini sahaja (DevOps FTW!), Dan ia hanya perlu diselesaikan selepas mencapai skala yang agak besar. Mungkin sekarang bukan masa terbaik untuk direka khas.

untuk hari ini (dan mereka yang berurusan dengan aplikasi dengan kerumitan yang rendah atau permintaan lalu lintas), pendekatan pertengahan yang bahagia adalah untuk mengimbangi banyak perkhidmatan biasa kepada penyedia pihak ketiga. Hampir semuanya kini tersedia sebagai perkhidmatan. Pekerjaan latar belakang, pemprosesan imej, pengesahan, analisis data, pembalakan, penghantaran e -mel, sistem beratur tidak perlu dibina dalam timbunan MVC yang sama, dan arkitek harus mempertimbangkan apa yang boleh dimuatkan ke sistem SaaS untuk bayaran bulanan yang rendah (iaitu, Carian algolia) atau perkhidmatan docker yang dibina khas yang mungkin berjalan di beberapa ruang awan yang mengendalikan pemprosesan imej yang menjengkelkan.

Titik di sini saya fikir adalah bahawa anda tidak boleh menyelam kepala ke dalam projek arkitek semula, jangan buang semua yang anda miliki hari ini, dan melepaskan kawanan Docker di mana sahaja anda boleh bayangkan. Asas untuk penambahbaikan boleh diperkenalkan secara beransur -ansur dengan decoupling bahagian yang mungkin, memahami kesesakan dalam sistem, dan menerapkan konsep pemisahan kebimbangan terhadap kawasan masalah ini.

Kesimpulan

2017 akan membawa kita lebih banyak perbualan dan penyebaran pengeluaran mengenai MOA berasaskan kontena. Pandangan dan omong kosong saya mengenai Docker, menggunakan Golang atau Node tidak bermaksud PHP adalah "mati" atau apa -apa seperti itu ... Saya rasa kita perlu tinggal di hadapan pek sebagai pemaju, jadi jika microservices berada di mana ia berada, Lalu mengapa tidak belajar Golang? Ia sesuai untuk membangunkan aplikasi kontena kecil (kerana jejak kecil, kelajuan cepat dan pemprosesan selari). Node dan Golang adalah menyeronokkan kerana mereka membolehkan anda membina perkhidmatan kecil yang merupakan sebahagian daripada suku besar yang menghubungkan mereka bersama -sama dan menerbitkannya sebagai kawanan epik untuk bekas docker jika anda lebih suka. Walau bagaimanapun, semua penyelesaian dan bahasa canggih yang hebat ini tidak bermakna bahawa PHP tidak lagi relevan atau "mati." Kami pasti akan membina timbunan MVC dan titik akhir API seketika.

Satu masalah yang belum diselesaikan dengan MOA ialah sementara bekas membantu kami menghapuskan aplikasi monolitik di belakang, kami masih menghadapi banyak isu seni bina di lapisan depan, UI, atau pandangan. Kami boleh membina aplikasi backend yang sangat kuat, tetapi akhirnya ia akan bertindak balas di JSON, yang mesti diberikan dalam aplikasi klien entah bagaimana. Adakah objek tindak balas akhir datang dari PHP yang mudah (contohnya, titik akhir yang didorong oleh lumen (URL)) atau satu siri unit keputusan dan pemprosesan yang dipadam oleh antara muka mesej? Ia sangat bergantung pada keperluan anda dan keperluan permohonan anda.

Tahun ini, belajar tentang Laravel, memberi tumpuan kepada Docker, Golang, dan benar -benar memberi tumpuan kepada penggunaan saluran paip. Penukaran dari tempatan ke pengeluaran harus lebih lancar daripada seketika, terutama ketika membina aplikasi MVC.

Soalan Lazim Mengenai Rangka Kerja PHP MVC

Apakah rangka kerja MVC dalam PHP?

rangka kerja-pemimpin-pemadatan (MVC) dalam PHP adalah corak reka bentuk yang membahagikan aplikasi ke dalam tiga komponen yang saling berkaitan. Komponen model sepadan dengan pengguna menggunakan logik yang berkaitan dengan semua data. Komponen paparan digunakan untuk semua logik UI aplikasi. Sebaliknya, pengawal bertindak sebagai antara muka antara model dan komponen paparan untuk mengendalikan semua logik perniagaan dan permintaan masuk.

Kenapa saya harus menggunakan rangka kerja MVC untuk pembangunan PHP?

Pembangunan PHP menggunakan rangka kerja MVC mempunyai banyak kelebihan. Ia memberikan pemisahan yang jelas mengenai kebimbangan, yang menjadikan kod lebih mudah untuk mengekalkan dan memahami. Ia juga menggalakkan kebolehgunaan semula dan skalabiliti kod, yang membolehkan pemaju membuat aplikasi yang mantap dan berskala besar. Di samping itu, rangka kerja MVC sering dilengkapi dengan alat dan perpustakaan terbina dalam untuk memudahkan tugas seperti abstraksi pangkalan data, pengesahan bentuk, sesi, dan pemprosesan cookie.

Apakah kerangka PHP MVC teratas pada tahun 2017?

Pada tahun 2017, beberapa kerangka PHP MVC teratas termasuk Laravel, Symfony, Codeigniter, YII2 dan CakePHP. Laravel sangat popular untuk sintaks elegannya, ciri -ciri yang kuat dan komuniti pemaju yang bersemangat. Symfony juga digunakan secara meluas untuk tahap fleksibiliti dan seni bina modular yang tinggi.

Bagaimana memilih rangka kerja PHP MVC yang tepat untuk projek saya?

Memilih rangka kerja PHP MVC yang betul bergantung kepada beberapa faktor, termasuk saiz dan kerumitan projek, kepakaran pasukan, komuniti kerangka dan sokongan, prestasi dan skalabilitasnya, dan keluk pembelajaran yang terlibat. Adalah disyorkan bahawa rangka kerja yang berbeza akan dikaji dan dibandingkan berdasarkan faktor -faktor ini sebelum membuat keputusan.

Bagaimana mod MVC berfungsi dalam rangka kerja PHP?

Dalam rangka PHP MVC, apabila pengguna menghantar permintaan, ia mula -mula pergi ke pengawal, yang mengenal pasti model yang sesuai untuk memproses data. Model itu kemudian berinteraksi dengan pangkalan data, memproses data dan menghantarnya kembali ke pengawal. Pengawal kemudian memuat paparan yang sepadan, yang membentangkan data kepada pengguna dalam format mesra pengguna.

Apa itu Laravel dan mengapa ia begitu popular?

Laravel adalah rangka kerja PHP MVC yang terkenal dengan sintaks elegan dan ciri -ciri yang kaya. Ia menyediakan pelbagai alat untuk penghalaan, pengesahan, sesi, caching dan tugas lain. Laravel juga mempunyai komuniti yang bersemangat dan sejumlah besar dokumentasi yang menjadikannya pilihan yang popular untuk pemaju.

Apakah lengkung pembelajaran rangka kerja PHP MVC?

Keluk pembelajaran rangka kerja PHP MVC mungkin berbeza -beza. Sesetengah rangka kerja seperti Laravel dan Codeigniter dikenali kerana kesederhanaan mereka dan agak mudah dipelajari. Rangka kerja lain seperti Symfony dan YII2 mungkin mengambil lebih banyak masa untuk menguasai kerana fungsi dan konsep mereka adalah kompleks.

Bolehkah saya menggunakan php tanpa rangka kerja MVC?

Ya, anda boleh menggunakan PHP tanpa rangka kerja MVC. Walau bagaimanapun, dengan menggunakan rangka kerja boleh menjadikan proses pembangunan anda lebih cekap dan kod anda lebih mudah dikekalkan, terutamanya dalam aplikasi yang besar.

Apakah Abstraksi Pangkalan Data dalam Rangka Kerja MVC PHP?

Abstraksi pangkalan data dalam rangka kerja PHP MVC merujuk kepada amalan menyembunyikan butiran operasi pangkalan data untuk mengelakkan mempengaruhi seluruh permohonan. Ini membolehkan pemaju berinteraksi dengan pangkalan data menggunakan API yang konsisten tanpa mengira sistem pangkalan data yang mendasari.

Bagaimana untuk memulakan dengan rangka kerja PHP MVC?

Untuk memulakan rangka kerja PHP MVC, anda harus terlebih dahulu memahami asas-asas pengaturcaraan PHP dan berorientasikan objek. Anda kemudian boleh memilih rangka kerja yang sesuai dengan keperluan anda dan mula belajar melalui dokumentasi rasmi, tutorial dalam talian, dan forum komuniti.

Atas ialah kandungan terperinci Negeri Rangka Kerja PHP MVC pada tahun 2017. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!