Apa itu MVC?

Sebagai seorang programmer yang serius, bagaimana Anda menjawab pertanyaan Apa itu MVC?

Dalam pikiran saya, MVC adalah semacam topik yang samar-samar - dan karena itu, jika audiens Anda adalah pelajar, maka Anda bebas untuk menggambarkannya secara umum yang tidak mungkin kontroversial.

Namun, jika Anda berbicara kepada audiens yang berpengetahuan luas, terutama pewawancara, saya mengalami kesulitan memikirkan arah untuk mengambil yang tidak mengambil risiko reaksi "baik itu tidak benar! ...". Kita semua memiliki pengalaman dunia nyata yang berbeda, dan saya belum pernah benar-benar bertemu pola implementasi MVC yang sama dua kali.

Secara khusus, tampaknya ada perbedaan pendapat tentang keketatan, definisi komponen, pemisahan bagian (bagian mana yang cocok), dll.

Jadi, bagaimana saya harus menjelaskan MVC dengan cara yang benar, singkat, dan tidak kontroversial?

MVC adalah arsitektur perangkat lunak - struktur sistem - yang memisahkan logika domain / aplikasi / bisnis (apa pun yang Anda inginkan) dari antarmuka pengguna lainnya. Ini dilakukan dengan memisahkan aplikasi menjadi tiga bagian: model, tampilan, dan pengontrol.

Model ini mengelola perilaku dan data dasar aplikasi. Ia dapat merespons permintaan informasi, merespons instruksi untuk mengubah keadaan informasinya, dan bahkan memberi tahu pengamat dalam sistem yang didorong oleh peristiwa ketika informasi berubah. Ini bisa berupa database, atau sejumlah struktur data atau sistem penyimpanan. Singkatnya, ini adalah data dan manajemen data aplikasi.

Tampilan secara efektif menyediakan elemen antarmuka pengguna aplikasi. Ini akan membuat data dari model menjadi bentuk yang cocok untuk antarmuka pengguna.

Pengontrol menerima input pengguna dan membuat panggilan ke objek model dan tampilan untuk melakukan tindakan yang sesuai.

Secara keseluruhan, ketiga komponen ini bekerja bersama untuk membuat tiga komponen dasar MVC.

Analogi

Saya menjelaskan MVC kepada ayah saya seperti ini:

MVC (Model, View, Controller) adalah pola untuk mengatur kode dalam aplikasi untuk meningkatkan rawatan.

Bayangkan seorang fotografer dengan kameranya di studio. Seorang pelanggan memintanya untuk mengambil foto sebuah kotak.

Kotak adalah model , fotografer adalah pengontrol dan kamera adalah pemandangan .

Karena kotak itu tidak tahu tentang kamera atau fotografer, ia sepenuhnya independen. Pemisahan ini memungkinkan fotografer untuk berjalan di sekitar kotak dan mengarahkan kamera di sudut manapun untuk mendapatkan bidikan / tampilan yang dia inginkan.

Arsitektur non-MVC cenderung terintegrasi dengan erat. Jika kotak, pengontrol, dan kamera adalah objek satu-dan-sama-maka, kita harus memisahkan dan kemudian membangun kembali baik kotak dan kamera setiap kali kita ingin mendapatkan tampilan baru. Juga, mengambil foto akan selalu seperti mencoba mengambil foto selfie - dan itu tidak selalu sangat mudah.

Penjelasan detail

Hanya setelah membaca pertanyaan / jawaban maillist berikut ini saya merasa seperti saya mengerti MVC. Kutipan: https://mail.python.org/pipermail/python-list/2006-January/394968.html

bwaha menulis:

Penulis merujuk ke mvctree.py di wxPython sebagai contoh desain MVC. Namun saya masih terlalu hijau sehingga saya menemukan contoh khusus itu terlalu kompleks dan saya tidak memahami pemisahan yang direkomendasikan oleh penulis.

MVC adalah tentang pemisahan masalah.

Model bertanggung jawab untuk mengelola data program (baik data pribadi maupun klien). View / Controller bertanggung jawab untuk menyediakan sarana bagi dunia luar untuk berinteraksi dengan data klien program.

Model menyediakan antarmuka internal (API) untuk mengaktifkan bagian lain dari program untuk berinteraksi dengannya. View / Controller menyediakan antarmuka eksternal (GUI / CLI / formulir web / IPC tingkat tinggi / dll.) Untuk memungkinkan semuanya melebihi program untuk berkomunikasi dengannya.

Model bertanggung jawab untuk menjaga integritas data program, karena jika itu rusak maka itu akan berakhir untuk semua orang. View / Controller bertanggung jawab untuk menjaga integritas UI, memastikan semua tampilan teks menampilkan nilai terbaru, menonaktifkan item menu yang tidak berlaku untuk fokus saat ini, dll.

Model tidak mengandung kode View / Controller; tidak ada kelas widget GUI, tidak ada kode untuk meletakkan kotak dialog atau menerima input pengguna. View / Controller tidak mengandung kode Model; tidak ada kode untuk memvalidasi URL atau melakukan kueri SQL, dan juga tidak ada status asli: setiap data yang dipegang oleh widget hanya untuk tujuan tampilan, dan hanya refleksi dari data sebenarnya yang disimpan dalam Model.

Sekarang, inilah tes dari desain MVC sejati: program pada dasarnya harus berfungsi penuh bahkan tanpa View / Controller terpasang. OK, dunia luar akan mengalami kesulitan berinteraksi dengan itu dalam bentuk itu, tetapi selama orang tahu mantra Model API yang sesuai, program akan menyimpan dan memanipulasi data seperti biasa.

Mengapa ini mungkin? Yah, jawaban sederhananya adalah itu semua berkat kopling rendah antara Model dan lapisan View / Controller. Namun, ini bukan cerita lengkapnya. Apa kunci untuk seluruh pola MVC adalah arah di mana koneksi tersebut berjalan: SEMUA instruksi mengalir dari View / Controller ke Model. Model TIDAK PERNAH memberi tahu View / Controller apa yang harus dilakukan.

Mengapa? Karena di MVC, sementara View / Controller diizinkan untuk mengetahui sedikit tentang Model (khususnya, API Model), tetapi Model tidak diizinkan untuk mengetahui apa pun tentang View / Controller.

Mengapa? Karena MVC adalah tentang menciptakan pemisahan keprihatinan yang jelas.

Mengapa? Untuk membantu mencegah kompleksitas program tidak terkendali dan mengubur Anda, pengembang, di bawahnya. Semakin besar program, semakin besar jumlah komponen dalam program itu. Dan semakin banyak koneksi yang ada di antara komponen-komponen itu, semakin sulit bagi pengembang untuk mempertahankan / memperluas / mengganti komponen individual, atau bahkan hanya mengikuti cara kerja seluruh sistem. Tanyakan kepada diri Anda sendiri: ketika melihat diagram struktur program, apakah Anda lebih suka melihat pohon atau tempat lahir kucing? Pola MVC menghindari yang terakhir dengan melarang koneksi melingkar: B dapat terhubung ke A, tetapi A tidak dapat terhubung ke B. Dalam hal ini, A adalah Model dan B adalah View / Controller.

BTW, jika Anda tajam, Anda akan melihat masalah dengan pembatasan 'satu arah' yang baru saja dijelaskan: bagaimana Model dapat menginformasikan View / Controller perubahan dalam data pengguna Model ketika Model bahkan tidak diizinkan untuk tahu bahwa View / Controller, apalagi mengirim pesan ke sana? Tapi jangan khawatir: ada solusi untuk ini, dan itu agak rapi bahkan jika itu tampak agak bundar pada awalnya. Kami akan kembali ke sana sebentar lagi.

Jadi, secara praktis, objek View / Controller dapat, melalui API Model, 1. memberi tahu Model untuk melakukan sesuatu (mengeksekusi perintah), dan 2. memberi tahu Model untuk memberikan sesuatu (mengembalikan data). Lapisan View / Controller mendorong instruksi ke lapisan Model dan menarik informasi dari lapisan Model.

Dan di situlah contoh MyCoolListControl pertama Anda salah, karena API untuk kelas itu mengharuskan informasi didorong ke dalamnya, jadi Anda kembali memiliki penggandaan dua arah di antara lapisan, melanggar aturan MVC dan membuang Anda kembali ke dalam Arsitektur cradle kucing yang Anda [mungkin] coba hindari di tempat pertama.

Sebagai gantinya, kelas MyCoolListControl harus mengikuti arus, menarik data yang dibutuhkan dari lapisan di bawah, saat dibutuhkan. Dalam kasus widget daftar, itu umumnya berarti menanyakan berapa banyak nilai yang ada dan kemudian meminta masing-masing item tersebut pada gilirannya, karena itu tentang cara paling sederhana dan paling longgar untuk melakukannya dan oleh karena itu menjaga agar penggandaan ada minimum. Dan jika widget ingin, katakanlah, untuk menyajikan nilai-nilai itu kepada pengguna dalam urutan abjad yang bagus maka itu adalah perogatifnya; dan tanggung jawabnya, tentu saja.

Sekarang, satu teka-teki terakhir, seperti yang saya sebutkan sebelumnya: bagaimana Anda menjaga tampilan UI disinkronkan dengan keadaan Model dalam sistem berbasis MVC?

Inilah masalahnya: banyak objek Tampilan stateful, misalnya kotak centang mungkin dicentang atau tidak dipilih, bidang teks mungkin berisi beberapa teks yang dapat diedit. Namun, MVC menentukan bahwa semua data pengguna disimpan dalam lapisan Model, sehingga setiap data yang disimpan oleh lapisan lain untuk tujuan tampilan (kondisi kotak centang, teks saat ini bidang teks) harus merupakan salinan tambahan dari data Model utama itu. Tetapi jika status Model berubah, salinan Lihat status itu tidak lagi akurat dan perlu diperbarui.

Tapi bagaimana caranya? Pola MVC mencegah Model mendorong salinan baru dari informasi itu ke dalam layer View. Heck, itu bahkan tidak memungkinkan Model untuk mengirim pesan Lihat untuk mengatakan keadaannya telah berubah.

Hampir saja. Oke, lapisan Model tidak diizinkan untuk berbicara langsung ke lapisan lain, karena untuk melakukannya akan memerlukannya tahu sesuatu tentang lapisan-lapisan itu, dan aturan MVC mencegahnya. Namun, jika sebuah pohon tumbang di hutan dan tidak ada yang mendengarnya, apakah itu mengeluarkan suara?

Jawabannya, Anda lihat, adalah untuk mengatur sistem notifikasi, memberikan lapisan Model tempat yang dapat diumumkan kepada siapa pun khususnya bahwa ia baru saja melakukan sesuatu yang menarik. Lapisan lain kemudian dapat memposting pendengar dengan sistem notifikasi untuk mendengarkan pengumuman yang mereka benar-benar tertarik. Lapisan Model tidak perlu tahu apa-apa tentang siapa yang mendengarkan (atau bahkan jika ada orang yang mendengarkan sama sekali!); hanya memposting pengumuman dan kemudian melupakannya. Dan jika ada yang mendengar pengumuman itu dan merasa ingin melakukan sesuatu setelahnya - seperti meminta Model untuk beberapa data baru sehingga dapat memperbarui tampilan di layarnya - sangat bagus. Model hanya mendaftar pemberitahuan apa yang dikirim sebagai bagian dari definisi API-nya; dan apa yang dilakukan orang lain dengan pengetahuan itu terserah mereka.

MVC dipertahankan, dan semua orang senang. Kerangka kerja aplikasi Anda mungkin menyediakan sistem pemberitahuan bawaan, atau Anda dapat menulis sendiri jika tidak (lihat 'pola pengamat').

...

Bagaimanapun, harapan itu membantu. Setelah Anda memahami motivasi di balik MVC, alasan mengapa segala sesuatunya dilakukan dengan cara mereka mulai masuk akal, bahkan ketika - pada pandangan pertama - mereka tampak lebih kompleks daripada yang diperlukan.

Tepuk tangan,

telah

MVC sebagian besar adalah kata kunci.

Dulu dianggap sebagai pola, tetapi definisi aslinya tahun 1979 telah dibuat-buat, diteruskan, disalahartikan, diambil di luar konteks aslinya. Sudah diredefinisi ke titik mulai menyerupai agama, dan sementara ini pasti membantu kultus kargo mempertahankannya, namanya tidak terkait lagi dengan seperangkat pedoman yang solid . Dengan demikian, itu tidak bisa dianggap sebagai pola lagi.

MVC tidak pernah dimaksudkan untuk menggambarkan aplikasi web.
Atau sistem operasi modern, atau bahasa.
(beberapa di antaranya benar-benar membuat definisi 1979 berlebihan)

Itu dibuat untuk. Dan itu tidak berhasil.

Kita sekarang berurusan dengan hibrida web-mvc cabul yang, dengan status kata kunci yang mengerikan, definisi buruk, dan memiliki programmer semi-buta huruf sebagai target demografis, membuat publikasi yang sangat buruk untuk pola perangkat lunak secara umum.

MVC, dengan demikian, menjadi pemisahan keprihatinan yang disaring untuk orang-orang yang tidak benar-benar ingin terlalu memikirkannya.

• Model data ditangani satu arah,
• yang melihat di tempat lain,
• sisanya hanya bernama "controller" dan diserahkan kepada kebijaksanaan pembaca.

Situs web / aplikasi web di tahun 90-an tidak benar-benar digunakan untuk menerapkan pemisahan masalah.

Itu adalah kesalahan kode spaghetti yang tercampur.
Perubahan UI, desain ulang, dan pengaturan ulang data sangat sulit, mahal, panjang, menyedihkan, bernasib buruk.

Teknologi web seperti ASP, JSP dan PHP membuatnya terlalu mudah untuk mencampurkan masalah tampilan dengan data, dan masalah aplikasi. Para pendatang baru di lapangan biasanya mengeluarkan bola-bola kode yang tidak bisa dipisahkan seperti di masa lalu.

Dengan demikian, semakin banyak orang mulai mengulangi "gunakan MVC" dalam loop tanpa akhir di forum dukungan. Jumlah orang meluas ke titik termasuk manajer dan pemasar, (untuk beberapa istilah sudah akrab, dari masa-masa dalam pemrograman gui, di mana polanya masuk akal) dan yang menjadi raksasa dari kata kunci yang harus kita hadapi sekarang .

Menurut akal sehat , bukan metodologi .
Ini adalah titik awal , bukan solusi .
Ini seperti memberi tahu orang untuk menghirup udara, atau membuat kegentingan , bukan obat kanker .

Cara terbaik untuk mendefinisikannya adalah dengan membuka tulisan asli Trygve Reenskaug , yang menciptakannya: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Makalah ini, khususnya, umumnya dianggap sebagai teks definisi: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MODEL

Model mewakili pengetahuan. Model dapat berupa objek tunggal (agak tidak menarik), atau bisa juga beberapa struktur objek ...

Harus ada korespondensi satu-ke-satu antara model dan bagian-bagiannya di satu sisi, dan dunia yang diwakili sebagaimana dirasakan oleh pemilik model di sisi lain. Node model karena itu harus mewakili bagian yang dapat diidentifikasi dari masalah.

Semua node dari suatu model harus berada pada level masalah yang sama, ini membingungkan dan dianggap sebagai bentuk yang buruk untuk menggabungkan node yang berorientasi masalah (mis. Janji kalender) dengan detail implementasi (misalnya paragraf).

LIHAT

Pandangan adalah representasi (visual) dari modelnya. Ini biasanya akan menyoroti atribut tertentu dari model dan menekan yang lain. Dengan demikian bertindak sebagai filter presentasi .

Suatu pandangan dilampirkan pada modelnya (atau bagian model) dan mendapatkan data yang diperlukan untuk presentasi dari model dengan mengajukan pertanyaan. Ini juga dapat memperbarui model dengan mengirim pesan yang sesuai. Semua pertanyaan dan pesan ini harus dalam terminologi model, oleh karena itu pandangan harus mengetahui semantik atribut dari model yang diwakilinya. (Ini mungkin, misalnya, meminta pengidentifikasi model dan mengharapkan contoh Teks, mungkin tidak menganggap bahwa model tersebut dari Teks kelas.)

PENGENDALIAN

Pengontrol adalah tautan antara pengguna dan sistem. Ini memberikan pengguna dengan input dengan mengatur tampilan yang relevan untuk menampilkan diri mereka di tempat yang tepat di layar. Ini menyediakan sarana untuk output pengguna dengan menghadirkan pengguna dengan menu atau cara lain untuk memberikan perintah dan data. Pengontrol menerima output pengguna tersebut, menerjemahkannya ke dalam pesan yang sesuai dan meneruskan pesan-pesan ini pada .untuk satu atau lebih tampilan.

Kontroler tidak boleh melengkapi pandangan, misalnya tidak pernah menghubungkan pandangan node dengan menggambar panah di antara mereka.

Sebaliknya, tampilan tidak boleh tahu tentang input pengguna, seperti operasi mouse dan penekanan tombol. Seharusnya selalu dimungkinkan untuk menulis metode dalam pengontrol yang mengirim pesan ke tampilan yang mereproduksi urutan perintah pengguna.

EDITOR

Kontroler terhubung ke semua pandangannya, mereka disebut bagian-bagian controller. Beberapa tampilan menyediakan pengontrol khusus, editor , yang memungkinkan pengguna untuk mengubah informasi yang disajikan oleh tampilan. Editor tersebut dapat disambungkan ke jalur antara pengontrol dan tampilan, dan akan bertindak sebagai perpanjangan dari pengontrol. Setelah proses pengeditan selesai, editor dihapus dari jalur dan dibuang.

Perhatikan bahwa editor berkomunikasi dengan pengguna melalui metafora tampilan yang terhubung, karena itu editor terkait erat dengan tampilan. Kontroler akan menghubungi editor dengan menanyakan tampilan untuknya - tidak ada sumber lain yang sesuai.

MVC adalah pola desain yang digunakan untuk mengisolasi logika bisnis dari presentasi.

Ini berbeda dari banyak pola desain lain dengan fakta bahwa biasanya tidak diimplementasikan secara ringkas, tetapi merupakan dasar dari suatu kerangka kerja.

Sementara aplikasi yang menerapkan pola Strategi hanyalah detail kecil tentang itu, mengatakan bahwa aplikasi web menggunakan pola desain MVC sangat menentukan arsitekturnya .

MVC adalah desain perangkat lunak yang memisahkan komponen sistem atau subsistem berikut:

1. Model - Data tentang status aplikasi atau komponennya. Dapat mencakup rutinitas untuk modifikasi atau akses.
2. Lihat - Penafsiran data (model). Ini hanya terbatas pada representasi visual, tetapi bisa berupa audio, informasi turunan (misalnya statistik yang disalurkan ke objek model lain), dll. Selain itu, model tunggal mungkin memiliki banyak tampilan.
3. Control - Menangani input eksternal ke sistem yang meminta modifikasi pada model. Kontrol / tampilan mungkin terkait erat (dalam hal UI). Namun, input eksternal lainnya (seperti perintah jaringan), dapat diproses yang sepenuhnya independen dari tampilan.

Saya akan mengatakan MVC adalah konsep atau keluarga dengan pola yang sama.

Saya pikir artikel ini layak dibaca. Arsitektur GUI oleh Martin Fowler

Pertama, Anda harus menentukan siapa penanya, dan jawaban seperti apa yang ia cari. Anda merespons pertanyaan ini dengan pertanyaan lain, seperti "Dalam arti apa?"

Anda dapat bertanya apakah mereka merujuk ke MVC secara umum, implementasi tertentu dari MVC (yaitu asp.net MVC, spring MVC, smalltalk MVC, dll.), Apa itu secara teknis, apa secara filisofis (ya, ia memiliki filsafat juga), dll.

Jika ini adalah pertanyaan pada tes, dan Anda tidak bisa meminta penanya untuk mengklarifikasi, maka Anda harus menebak berdasarkan konteksnya.

Jawaban yang bagus dan sederhana adalah:

MVC adalah arsitektur antarmuka pengguna perangkat lunak yang digunakan untuk memisahkan masalah struktural dan perilaku untuk memfasilitasi perangkat lunak yang lebih dapat dirawat.

Anda juga bisa mengatakan:

Dengan memisahkan View dari Controller dari Model, itu mendorong isolasi komponen berdasarkan tanggung jawab mereka. Secara teori, dan biasanya dalam praktiknya, ini membantu meningkatkan kemampuan rawat dengan mencegah berbagai bagian sistem saling berbaur dan menciptakan sistem yang lebih kompleks.

Tetapi, pada akhirnya, Anda akan dinilai apakah Anda memberikan jawaban yang mereka harapkan. Satu-satunya solusi untuk masalah ini adalah mencari tahu jawaban seperti apa yang mereka harapkan.

Inilah yang akan saya katakan tentang itu. Saya akan mencoba menjelaskannya dalam hal aplikasi mobile, karena ini adalah yang paling saya kenal dan karena saya pikir saya tidak sepenuhnya memahaminya sebelum mulai melakukan aplikasi mobile.
Mari kita ambil Android sebagai contoh.
Lapisan presentasi, yaitu. antarmuka pengguna dapat (harus, paling sering) ditentukan seluruhnya dalam xml. Untuk mempermudah, misalkan satu file xml menjelaskan satu layar dalam aplikasi. File XML menentukan kontrol, tata letak kontrol, penentuan posisi, warna, ukuran, label string ... semuanya tentang presentasi. Namun ia tidak tahu kapan akan dipanggil, kapan akan diletakkan di layar. Apakah itu tata letak yang berdiri sendiri atau bagian dari tata letak yang lebih besar? Itu dia: PANDANGAN sempurna Anda .

Sekarang, tampilan jelas perlu ditempatkan di layar di beberapa titik, jadi bagaimana seharusnya melakukannya? Your CONTROLLER , di Android disebut Activity. Seperti namanya, aktivitas melakukan beberapa aktivitas. Sekalipun tujuan utamanya adalah untuk menampilkan tampilan yang ditentukan pada langkah 1, ia akan melakukan beberapa tindakan. Jadi, aktivitas mengambil tampilan dan menampilkannya di layar. Karena pandangan tidak tahu apa-apa tentang aktivitas, aktivitas yang sama tidak tahu apa-apa tentang presentasi aktual. Kami (pemrogram) dapat mengatur ulang tata letak tampilan beberapa kali, tanpa mengubah satu baris kode pun dalam aktivitas kami.

Sekarang, tidak ada banyak gunanya dalam menyajikan tata letak xml bagus Anda yang mengkilap dan terdefinisi dengan baik tanpa benar-benar melakukan sesuatu. Katakanlah kita ingin menyimpan data yang dimasukkan oleh pengguna. Aktivitas perlu menangani proses ini mulai dari mengambil data dari pengguna hingga meneruskannya ke orang lain untuk menanganinya (memproses, menyimpannya, menghapusnya). Kepada siapa akan lulus? Nah, untuk MODEL . Saya suka menganggap model sebagai murni. kelas java yang tidak tahu apa-apa tentang konteks aplikasi tempat tinggalnya (dalam praktiknya hampir tidak akan pernah terjadi).

Katakanlah saya memiliki Person kelas yang memiliki tiga properti: nama, alamat, umur. Layout yang didefinisikan XML saya memiliki 3 bidang untuk input pengguna: nama, alamat, usia. Aktivitas saya mengambil tiga nilai dari input pengguna, membuat objek Person baru dan memanggil beberapa metode di atasnya yang tahu bagaimana menangani beberapa logika khusus Person. Itu dia. Model-View-Controller.

Saya selalu memulai dengan mengatakan kepada mereka bahwa polanya bukan sesuatu yang baru dan telah ada selama bertahun-tahun ... pada saat ini mereka memberi saya pandangan ingin tahu dan BAM !, mereka terpikat:

Dan kemudian saya akan berbicara banyak tentang berbagai poin seperti jawaban sebelumnya, tapi saya pikir ini penting untuk kontekstual, seperti yang dikatakan JB King, ASP.NET MVC dll,