Secara konseptual saya mencoba memahami jika saya harus melakukan ini:
item = Model()
screen = View()
brain = Controller(item, screen)
atau ini..
brain = Controller()
item = Model(brain)
screen = View(brain)
atau ini..
class Controller():
def __init__(self):
item = Model(self)
screen = View(self)
atau sesuatu yang lain sama sekali?
Jawaban:
Bagi saya, opsi pertama masuk akal. Tugas Pengontrol adalah mengoordinasikan antara tampilan dan model. Dari sudut pandang itu, masuk akal bagi pengontrol untuk menjadi orang yang mengontrol referensi ke pandangan dan model.
Anda tidak dapat benar-benar memiliki pengontrol tanpa Model dan Tampilan, namun jauh lebih masuk akal untuk hanya memiliki Tampilan atau hanya memiliki Model (misalnya, dalam pengujian unit). Itu sebabnya Anda ingin meneruskan dependensi itu ke Controller, dan bukan dua lainnya.
The Modeldan Viewindependen satu sama lain.
Jangan menganggapnya Controllersebagai otak struktur MVC. Anggap saja sebagai pengirim yang menangani permintaan dari browser, dan kirim ke Model. Ini kemudian mengambil data dari Modeldan mengemasnya dengan cara yang ramah template , dan kemudian mengirimkannya ke a View.
The Modeladalah otak dalam struktur MVC, dan ini adalah di mana Anda harus meletakkan aturan bisnis Anda. Aturan bisnis adalah umum di beberapa pengendali . Jadi pengontrol dokumen , dan pengontrol laporan dapat menggunakan model Pengguna untuk melihat siapa yang memiliki akses ke hal-hal tersebut. Anda tidak ingin mengulangi aturan itu di kedua pengontrol.
The Viewharus menggunakan template HTML untuk menyajikan data dengan cara tertentu non-sumber data. Seharusnya tidak terikat erat dengan skema database Anda. Untuk menunjukkan judul dokumen Anda akan memiliki tampilan yang menampilkan isi dari variabel templat yang disebut document_title, dan hanya yang Controllertahu bagaimana variabel itu ditetapkan, dan hanya yang Modeltahu mengapa dokumen tersebut memiliki judul itu.
MVC pada awalnya didefinisikan untuk memudahkan pemrograman aplikasi desktop. Tampilan berlangganan acara model, memperbarui presentasi ketika model berubah. Kontroler hanya menerjemahkan peristiwa antarmuka pengguna (misalnya, tekan tombol) menjadi panggilan ke model. Jadi pengontrol dan tampilan tergantung pada model, tetapi tidak tergantung satu sama lain. Model itu independen dari keduanya. Ini memungkinkan banyak tampilan dan pengontrol bekerja pada model yang sama.
Arsitektur "MVC" yang digunakan untuk aplikasi web 1.0 (refresh halaman penuh, tanpa AJAX) agak berbeda. Permintaan web dikirim ke pengontrol. Pengontrol entah bagaimana memodifikasi keadaan model, kemudian mengirimkan satu atau lebih model yang akan ditampilkan oleh tampilan. Pengontrol dan tampilan keduanya bergantung pada model, tetapi pengontrol juga tergantung pada tampilan.
Dengan aplikasi web 2.0, kami kembali ke arsitektur MVC klasik, di sisi klien . Model, tampilan, dan pengontrol semua berada di sisi klien sebagai objek Javascript. Pengontrol menerjemahkan peristiwa pengguna ke tindakan model. Tindakan model mungkin atau mungkin tidak menghasilkan permintaan AJAX ke server. Sekali lagi, tampilan berlangganan acara model dan memperbarui presentasi sesuai.
Tampilan harus berlangganan perubahan dalam model. Ada kelimpahan dalam kekayaan langganan karena dapat dirinci (tunjukkan perubahan inventaris untuk item tertentu ini) atau generik (model telah berubah); tampilan dapat meminta model sebagai respons terhadap perubahan pemberitahuan. Tampilan menyajikan serangkaian elemen model yang diinginkan di layar, memperbarui layar seperti saat menangani pemberitahuan perubahan.
Pengontrol harus mendorong perubahan pada model, sebagai hasil dari arah pengguna (mis. Perintah keyboard pada put, mouse & menu).
Model mempertahankan model dan daftar langganan, dan harus memberitahukan pandangan tentang perubahan yang berlaku melalui langganan mereka.
Juga perlu ada mekanisme untuk membuat view dan controller baru (karena dalam MVC Anda harus dapat memiliki dua atau lebih view dari model yang sama (mereka bisa saja view yang sama (point) atau view yang berbeda (point) s). Secara logis, kita dapat mempertimbangkan bahwa pengontrol perlu melakukan atau memiliki akses ke pabrik tampilan & pengontrol (pasangan), yang dapat menjadi bagian dari pengontrol atau komponen lain.
Modelsjangan beri tahu Views. Controllerskueri Modeluntuk perubahan, lalu render Viewsuntuk menyajikan perubahan itu.
MVC lebih seperti pola modularitas. Tujuannya adalah bahwa setiap kali Anda ingin mengubah tata letak antarmuka pengguna (tampilan), Anda tidak perlu mengubah logika aplikasi (pengontrol) atau pemrosesan data internal (model).
Untuk mencapai ini, polanya adalah untuk mengisolasi logika implementasi dari setiap komponen MVC. Namun, sangat normal bahwa ada komponen yang saling mengenal antarmuka .
Apa yang sering saya lihat adalah bahwa pengontrol membuat atau memanggil model dan tampilan (sehingga mengetahui antarmuka mereka) dan model atau tampilan dapat memberi tahu pengontrol sebagai balasannya (lebih seperti panggilan balik, atau pola pengamat). Bagian yang penting adalah bahwa pengontrol tidak mengetahui struktur tata letak.