Pada MVC dapatkah beberapa tampilan memiliki pengontrol yang sama atau satu tampilan harus memiliki satu pengontrol unik?

Saya punya beberapa pertanyaan saat merancang arsitektur untuk proyek di sekitar MVC. (Ini adalah proyek C ++ / Marmalade SDK, saya tidak menggunakan kerangka kerja MVC tertentu, saya membuatnya.)

Pada beberapa artikel (seperti pada artikel Steve Burbek asli ) saya terus membaca konsep "triad MVC" yang menghalangi saya karena saya mengambil konsep ini secara harfiah. Ketika saya membacanya pertama kali tampak seperti aplikasi dibangun di sekitar "MVC triad" unit - satu untuk setiap bagian UI yang saya kira -, tapi saya menemukan ini agak tidak fleksibel dan saya pikir bukan itu cara MVC dimaksudkan untuk digunakan. Kemudian, meneliti lebih lanjut tentang masalah ini, saya menemukan beberapa contoh kopling ketat dari pengontrol dan tampilan, yaitu, hubungan 1-ke-1 - TextEditView memiliki TextEditController.

Tetapi ketika saya kembali ke proyek saya, saya menemukan bahwa mungkin berguna untuk memiliki satu pengontrol (dengan 'unit logis', seperti AddElementController) dan beberapa tampilan untuk pengontrol tertentu.

Saya jelas berpikir tentang sesuatu seperti AddElementController yang seharusnya memiliki semacam UI tab. Haruskah saya memiliki AddElementController yang memiliki AddElementTabView dan beberapa AddImageView, AddSoundView, dll untuk tab? Atau haruskah saya memiliki 'sub-controller' yang berbeda untuk setiap tampilan tab?

Singkatnya, dan mengenai pola MVC (bukan kerangka kerja X, pemahaman / implementasi pola ini), apakah benar memiliki beberapa tampilan untuk suatu pengontrol atau haruskah masing-masing pandangan memiliki pengontrol tertentu?

Juga, apakah benar menyimpan beberapa informasi status pada pengontrol atau haruskah stateless (artinya state harus ditempatkan pada beberapa model state non-domain)?

Terima kasih untuk semuanya.

Masalahnya adalah bahwa pola MVC dirancang dalam sistem yang tidak benar-benar ada lagi. Itu ditemukan di Smalltalk pada saat perpustakaan UI tidak ada. Untuk membuat dialog jendela Anda menggambar semua kotak, sorot kotak yang sesuai, pastikan bahwa teks yang Anda gambar berakhir di tempat yang tepat ... dll ...

Bayangkan bagaimana rasanya menulis aplikasi dialog hanya menggunakan satu kanvas besar. Dari situlah dunia MVC berasal.

"Tampilan" dalam sistem ini adalah kotak teks dan itu adalah kelas yang bertanggung jawab untuk menggambar kotak, teks, menggambar area yang dipilih, menanggapi perubahan dalam teks, dll ...

"Pengontrol" adalah kelas lain yang mengambil peristiwa mouse yang terjadi di dalam kotak ini seperti mouse bergerak, tombol turun, tombol naik, klik, dll ... dan itu akan memutuskan apa yang terjadi. Haruskah kita mengubah teksnya? Haruskah kita mengubah pilihan? Hal-hal seperti itu.

"Model" adalah kelas lain yang mewakili data dasar dan keadaan komponen. Model kotak teks akan memiliki teks saja, font, seleksi, dll ...

Seperti yang Anda lihat, dalam situasi seperti ini, ketiga komponen ini sangat terjerat dalam representasi satu ide. Masuk akal dalam konteks ini untuk berbicara tentang "triad".

Hari ini, jika Anda bekerja membuat perpustakaan UI dan menggunakan perintah menggambar mentah, Anda mungkin melakukan hal serupa. Tetapi penerapan pola "MVC" telah menyebar melampaui tujuan awalnya. Sekarang, Anda memiliki "tampilan" yang sebenarnya bisa berupa dialog lengkap, dan pengontrol yang merespons acara seperti "textChanged" atau "buttonClicked". Model dalam MVC hari ini biasanya sesuatu yang cukup terputus dari sistem (tetapi umumnya terkait dengan tampilan dengan menyediakan antarmuka pengamat semacam) dan mungkin ada banyak pandangan yang terkait dengan satu model.

Dalam sebuah sistem yang baru-baru ini saya buat, misalnya, kami memiliki sekitar 10+ tampilan, semua mengamati satu "pemegang" dokumen tunggal dan dokumen aktifnya. Antarmuka gambar utama berinteraksi dengan tata letak dokumen, berbagai tampilan properti yang mengamati item yang dipilih dan memberikan antarmuka catatan, dan representasi skala kecil dari tampilan utama yang menunjukkan seluruh dokumen, bukan hanya jendela yang terlihat. Beberapa pandangan ini memiliki pengontrol kompleksitas yang beragam yang mengubah peristiwa GUI menjadi perubahan pada dokumen, yang pada gilirannya akan memberitahukan berbagai pandangannya.

Masih bisakah Anda menyebut hubungan seperti itu sebagai "triad"? Mungkin, tapi saya pikir itu menyiratkan terlalu banyak dari aplikasi MVC yang lebih tua.

Bisakah Anda membagikan pengontrol dengan tampilan berbeda? Tergantung pada seberapa mirip pandangannya. Saya telah menemukan bahwa secara umum jenis objek ini memiliki perilaku khusus untuk tampilan yang dikontrol DAN model yang dimanipulasi menjadi sangat dapat digunakan kembali ... tetapi selalu ada pengecualian.

Tergantung. Ada beberapa varian MVC, beberapa di mana hanya hubungan 1: 1 yang masuk akal (seperti "kotak dialog sederhana"), yang lain di mana ini bukan masalahnya. Saya akan merekomendasikan untuk membaca seri artikel " Build Your Own CAB ", menjelaskan varian MVC yang paling penting.

Tampilan tidak memiliki Pengontrol di MVC. Pengendali adalah bos, sehingga Pengendali memutuskan Tampilan mana yang akan diberikan dan Tampilan tidak / tidak peduli Pengontrol mana yang meminta Tampilan.

Anda dapat / akan benar-benar memiliki banyak Tampilan dari Pengendali. Bayangkan saja membuat model untuk setiap tampilan jika Anda ingin tetap dengan pola MVC.

Inti dari pengontrol adalah untuk mengontrol interaksi pengguna dengan model domain Anda - yaitu, itu adalah tingkat tipuan antara apa yang dilihat pengguna (tampilan) dan keadaan aplikasi Anda (model).

Ketika pengguna membuat permintaan, itu diarahkan ke controller. Pengontrol memutuskan bagaimana menyampaikan permintaan itu ke aplikasi, biasanya melalui semacam kelas layanan. Kemudian menginterpretasikan respons dari kelas layanan itu dan memutuskan tampilan apa yang akan dikirim kembali ke pengguna.

Kontroler selalu dapat mengembalikan tampilan yang sama (1: 1) jika hanya ada satu jenis permintaan yang dapat dibuat pengguna dari kontroler, dan selalu membutuhkan respons yang sama. Misalnya, HelloWorldControllerselalu akan HelloWorldViewmenampilkan "Hello, World!"

Di sisi lain, pengontrol sering harus memutuskan pandangan yang berbeda, tergantung pada apa yang dikatakan model itu. The TeamRosterControllermungkin mengembalikan RugbyTeamRosterViewatau FootbalTeamRosterView, tergantung pada jenis tim yang diminta.

Secara umum, lebih disukai pengendali tidak memiliki kewarganegaraan, meskipun beberapa akses ke keadaan sesi pengguna mungkin diperlukan atau diinginkan. Anda harus mengelola akses ke keadaan itu secara terpisah jika memungkinkan.

Saya sangat merekomendasikan melihat kerangka kerja MVC yang sebenarnya untuk melihat apa yang dilakukannya dan bagaimana cara kerjanya. Anda tidak harus menggunakannya, tetapi Anda pasti akan mendapatkan pemahaman yang lebih baik sebelum membangunnya sendiri.