Apa pola HMVC?

Membaca dokumentasi Kohana, saya menemukan bahwa perbedaan utama dalam versi 3.0 adalah bahwa ia mengikuti pola HMVC bukannya MVC seperti versi 2.x. Halaman tentang ini di dokumen Kohana dan yang ada di wikipedia tidak benar-benar memberi saya ide yang jelas.

Jadi pertanyaan: apa pola HMVC dan apa bedanya dengan MVC?

Sam de Freyssinet (salah satu pengembang Kohana) menulis artikel yang agak mendalam tentang HMVC , apa itu, dan bagaimana itu bisa digunakan.

Tautan sudah mati: Tautan Baru - https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/

Saat ini saya sedang dalam proses mengembangkan kerangka kerja PHP 5.3 HMVC saya sendiri yang disebut Alloy . Karena saya banyak berinvestasi dan dijual di HMVC, saya pikir saya bisa menawarkan sudut pandang yang berbeda, dan mungkin penjelasan yang lebih baik tentang mengapa HMVC harus digunakan dan manfaat yang dihasilkannya.

Manfaat praktis terbesar dari menggunakan arsitektur HMVC adalah "widgetisasi" dari struktur konten. Contohnya bisa berupa komentar, peringkat, Twitter atau blog, tampilan umpan RSS, atau tampilan konten keranjang belanja untuk situs web e-commerce. Ini pada dasarnya adalah sepotong konten yang perlu ditampilkan di beberapa halaman, dan mungkin bahkan di tempat yang berbeda, tergantung pada konteks permintaan HTTP utama.

Kerangka kerja MVC tradisional umumnya tidak memberikan jawaban langsung untuk jenis-jenis struktur konten ini, sehingga orang-orang pada akhirnya akan menduplikasi dan mengubah tata letak, menggunakan bantuan khusus, membuat struktur widget atau file pustaka sendiri, atau menarik data yang tidak terkait dari permintaan utama. Controller untuk mendorong ke View dan merender secara parsial. Tak satu pun dari ini adalah opsi yang sangat baik, karena tanggung jawab memberikan bagian tertentu dari konten atau memuat data yang diperlukan akhirnya bocor ke beberapa area dan mendapatkan duplikat di tempat itu digunakan.

HMVC, atau secara khusus kemampuan untuk mengirim sub-permintaan ke Pengendali untuk menangani tanggung jawab ini adalah solusi yang jelas. Jika Anda berpikir tentang apa yang Anda lakukan, itu cocok dengan struktur Pengontrol tepat. Anda perlu memuat beberapa data tentang komentar, dan menampilkannya dalam format HTML. Jadi Anda mengirim permintaan ke Controller komentar dengan beberapa params, itu berinteraksi dengan Model, memilih Tampilan, dan Tampilan menampilkan konten. Satu-satunya perbedaan adalah Anda ingin komentar yang ditampilkan sebaris, di bawah artikel blog yang dilihat pengguna alih-alih halaman komentar lengkap yang sepenuhnya terpisah (meskipun dengan pendekatan HMVC, Anda sebenarnya dapat melayani permintaan internal dan eksternal dengan pengontrol yang sama dan "mematikan dua burung dengan satu batu ", seperti kata pepatah). Dalam kasus ini, HMVC benar-benar hanya produk sampingan alami dari berjuang untuk peningkatan modularitas kode, dapat digunakan kembali, dan mempertahankan pemisahan masalah yang lebih baik. INI adalah titik penjualan HMVC.

Jadi, sementara artikel TechPortal Sam de Freyssinet tentang penskalaan dengan HMVC menarik untuk dipikirkan, bukan di mana 90% orang yang menggunakan kerangka kerja HMVC akan mendapatkan manfaat nyata, praktis, sehari-hari darinya.

HMVC terkait erat dengan pendekatan "berbasis komponen" untuk pengiriman. Pada dasarnya, alih-alih memiliki satu operator, yang mendelegasikan ke controller, masing-masing controller dapat bertindak sebagai dispatcher itu sendiri. Ini memberi Anda hierarki pengendali. Desainnya lebih fleksibel dan menyebabkan enkapsulasi kode yang lebih baik, tetapi dengan harga abstraksi yang lebih tinggi. Konstrukt dirancang di sekitar pola ini.

Lihat juga jawaban ini: /programming/115629/simplest-php-routing-framework/120411#120411

Di Kohana, setidaknya, permintaan HMVC adalah permintaan HTTP yang dilayani "secara internal": alih-alih dikeluarkan melalui jaringan, itu dialihkan, dikirim dan ditangani oleh kerangka itu sendiri. Kesamaan nama "HMVC" dan "MVC" membingungkan karena menunjukkan hubungan mendasar antara istilah yang sebenarnya tidak ada: satu bukan varian kecil atau modifikasi yang lain, mereka adalah hal yang sama sekali berbeda. (HMVC juga digambarkan sebagai Ajax tanpa permintaan HTTP sisi klien.) Penekanan Kohana pada, dan dukungan untuk "HMVC" berarti bahwa kerangka kerja tersebut memiliki dukungan kuat untuk arsitektur berorientasi layanan berbasis HTTP.

Keuntungan dari pola arsitektur ini adalah bahwa karena "konvensi panggilan" yang sama digunakan untuk permintaan internal dan eksternal, itu sepele untuk mengubah permintaan layanan "internal" menjadi permintaan "eksternal" atau sebaliknya ketika diperlukan.

Sementara ini adalah pola arsitektur yang masuk akal, memberikan namanya sendiri tampaknya tidak perlu (Symfony2 menggambarkan konsep yang sama " sub-permintaan "), dan pada kenyataannya nama tersebut tampaknya keliru: tidak ada persyaratan atau kebutuhan khusus bahwa permintaan membentuk suatu hierarki (selain grafik panggilan standar setiap program penting); permintaan bisa dengan mudah bersifat rekursif, misalnya.

[ Pembaruan Apr 2011, Mar 2012: Diperluas pada jawaban dalam menanggapi komentar.]

HMVC adalah Hierarchical Model View Controller. Dalam MVC normal, setiap objek GUI memiliki MVC-nya. Tetapi tidak ada hubungan antara objek GUI induk dan objek GUI anak, tidak seperti HMVC. Dalam HMVC setiap objek GUI memiliki akses ke objek anaknya dan masing-masing objek anak dapat mengakses ke objek induknya.

Jadi di setiap tampilan ada tampilan induk. Melalui itu dapat mengaksesnya tampilan induk. Karena di setiap pengontrol terdapat pengontrol induk yang dapat digunakan untuk meneruskan acara tersebut ke pengontrol induk (Jika acara tidak berada dalam cakupannya.)

Untuk keterangan rinci, silakan klik di sini

Tautan baru adalah alamat ini