Apa perbedaan antara MVC dan MVVM? [Tutup]

Apakah ada perbedaan antara pola "Model View Controller" standar dan pola Model / View / ViewModel Microsoft?

MVC / MVVM bukan merupakan pilihan / atau .

Dua pola muncul, dengan cara yang berbeda, dalam pengembangan ASP.Net dan Silverlight / WPF.

Untuk ASP.Net, MVVM digunakan untuk mengikat data dua arah dalam tampilan. Ini biasanya merupakan implementasi sisi klien (misalnya menggunakan Knockout.js). MVC di sisi lain adalah cara untuk memisahkan masalah di sisi server .

Untuk Silverlight dan WPF, pola MVVM lebih mencakup dan dapat muncul untuk bertindak sebagai pengganti MVC (atau pola lainnya dari mengorganisir perangkat lunak ke tanggung jawab yang terpisah). Salah satu asumsi, yang sering keluar dari pola ini, adalah bahwa ViewModelhanya menggantikan controller dalam MVC(seperti jika Anda hanya bisa menggantikan VMuntuk Cdalam akronim dan semua akan diampuni) ...

ViewModel tidak serta - merta menggantikan kebutuhan akan Pengontrol terpisah.

Masalahnya adalah: agar dapat diuji secara independen *, dan terutama dapat digunakan kembali ketika diperlukan, model tampilan tidak tahu tampilan apa yang ditampilkan, tetapi yang lebih penting tidak tahu dari mana datanya berasal .

* Catatan: dalam praktiknya Pengontrol menghapus sebagian besar logika, dari ViewModel, yang memerlukan pengujian unit. VM kemudian menjadi wadah bodoh yang membutuhkan sedikit, jika ada, pengujian. Ini adalah hal yang baik karena VM hanyalah jembatan, antara perancang dan pembuat kode, jadi harus tetap sederhana.

Bahkan dalam MVVM, pengontrol biasanya akan berisi semua logika pemrosesan dan memutuskan data apa yang akan ditampilkan di mana tampilan menggunakan model tampilan mana.

Dari apa yang telah kita lihat sejauh ini manfaat utama dari pola ViewModel untuk menghapus kode dari kode XAML di belakang untuk menjadikan XAML mengedit tugas yang lebih mandiri . Kami masih membuat pengontrol, sebagaimana dan ketika diperlukan, untuk mengontrol (tidak ada permainan kata-kata) logika keseluruhan aplikasi kami.

Pedoman dasar MVCVM yang kami ikuti adalah:

• Tampilan menampilkan bentuk data tertentu . Mereka tidak tahu dari mana data itu berasal.
• ViewModels menyimpan bentuk data dan perintah tertentu , mereka tidak tahu dari mana data, atau kode, berasal atau bagaimana itu ditampilkan.
• Model menyimpan data aktual (berbagai konteks, penyimpanan, atau metode lain)
• Pengendali mendengarkan, dan mempublikasikan, acara. Pengendali menyediakan logika yang mengontrol data apa yang dilihat dan di mana. Pengendali menyediakan kode perintah ke ViewModel sehingga ViewModel sebenarnya dapat digunakan kembali.

Kami juga mencatat bahwa kerangka kode-Patung pahat mengimplementasikan MVVM dan pola yang mirip dengan Prism DAN juga membuat ekstensif menggunakan pengontrol untuk memisahkan semua logika use-case.

Jangan menganggap pengontrol dibuat usang oleh View-model.

Saya telah memulai sebuah blog tentang topik ini yang akan saya tambahkan sesering mungkin . Ada masalah dengan menggabungkan MVCVM dengan sistem navigasi umum, karena sebagian besar sistem navigasi hanya menggunakan Views dan VM, tetapi saya akan membahasnya dalam artikel-artikel selanjutnya.

Manfaat tambahan menggunakan model MVCVM adalah bahwa hanya objek pengontrol yang perlu ada dalam memori untuk masa pakai aplikasi dan pengontrol terutama berisi kode dan sedikit data keadaan (yaitu memori kecil di atas kepala). Ini membuat aplikasi yang jauh lebih sedikit menggunakan memori daripada solusi di mana model tampilan harus dipertahankan dan sangat ideal untuk jenis pengembangan ponsel tertentu (misalnya Windows Mobile menggunakan Silverlight / Prism / MEF). Ini tentu saja tergantung pada jenis aplikasi karena Anda mungkin masih perlu mempertahankan VM yang di-cache sesekali untuk responsif.

Catatan: Posting ini telah diedit beberapa kali, dan tidak secara khusus menargetkan pertanyaan sempit yang diajukan, jadi saya telah memperbarui bagian pertama yang sekarang mencakup itu juga. Sebagian besar diskusi, dalam komentar di bawah ini, hanya berkaitan dengan ASP.Net dan bukan gambaran yang lebih luas. Posting ini dimaksudkan untuk mencakup penggunaan MVVM yang lebih luas di Silverlight, WPF dan ASP.Net dan mencoba untuk mencegah orang mengganti pengontrol dengan ViewModels.

Saya pikir cara termudah untuk memahami apa yang dimaksud dengan akronim ini adalah dengan melupakannya sejenak. Alih-alih, pikirkan perangkat lunak yang mereka gunakan, masing-masing. Itu benar-benar bermuara pada perbedaan antara web awal dan desktop.

Ketika mereka tumbuh dalam kompleksitas pada pertengahan 2000-an, pola desain perangkat lunak MVC - yang pertama kali dijelaskan pada 1970-an - mulai diterapkan pada aplikasi web. Pikirkan database, halaman HTML, dan inbetween kode. Mari kita perbaiki ini sedikit untuk sampai di MVC: Untuk »database«, mari kita asumsikan basis data dan kode antarmuka. Untuk »halaman HTML«, mari kita asumsikan templat HTML plus kode pemrosesan templat. Untuk »kode inbetween«, mari kita asumsikan pemetaan kode klik pengguna untuk tindakan, mungkin mempengaruhi database, pasti menyebabkan tampilan lain ditampilkan. Itu dia, setidaknya untuk tujuan perbandingan ini.

Mari kita mempertahankan satu fitur dari hal-hal web ini, bukan seperti sekarang ini, tetapi seperti yang ada sepuluh tahun yang lalu, ketika JavaScript adalah gangguan rendah, tercela, yang dilakukan oleh para programmer sejati untuk menghindari: Halaman HTML pada dasarnya bodoh dan pasif . Browser adalah klien yang tipis, atau jika Anda mau, klien yang buruk. Tidak ada intelijen di browser. Aturan memuat ulang halaman penuh. Tampilan »« dihasilkan kembali setiap kali.

Mari kita ingat bahwa cara web ini, meskipun sangat populer, sangat terbelakang dibandingkan dengan desktop. Aplikasi desktop adalah klien gemuk, atau klien kaya, jika Anda mau. (Bahkan program seperti Microsoft Word dapat dianggap sebagai semacam klien, klien untuk dokumen.) Mereka adalah klien yang penuh kecerdasan, penuh pengetahuan tentang data mereka. Mereka stateful. Mereka menyimpan data yang mereka tangani dalam memori. Tidak ada omong kosong seperti memuat halaman penuh.

Dan cara desktop yang kaya ini mungkin dari mana akronim kedua berasal, MVVM. Jangan tertipu oleh surat-surat, dengan kelalaian dari C. Pengendali masih ada. Mereka harus. Tidak ada yang dihapus. Kami hanya menambahkan satu hal: status, data yang di-cache pada klien (dan bersamaan dengan itu kecerdasan untuk menangani data itu). Data itu, pada dasarnya adalah cache pada klien, sekarang disebut »ViewModel«. Itulah yang memungkinkan interaktivitas yang kaya. Dan itu saja.

• MVC = model, controller, view = intinya komunikasi satu arah = interaktivitas yang buruk
• MVVM = model, pengontrol, cache, view = komunikasi dua arah = interaktivitas kaya

Kita dapat melihat bahwa dengan Flash, Silverlight, dan - yang paling penting - JavaScript, web telah memeluk MVVM. Browser tidak lagi dapat secara sah disebut thin client. Lihatlah kemampuan pemrograman mereka. Lihatlah konsumsi memori mereka. Lihatlah semua interaktivitas Javascript di halaman web modern.

Secara pribadi, saya menemukan teori dan bisnis akronim ini lebih mudah untuk dipahami dengan melihat apa yang dimaksud dalam realitas nyata. Konsep abstrak bermanfaat, terutama ketika diperlihatkan pada masalah konkret, sehingga pemahaman bisa jadi lingkaran penuh.

MVVM Model-View ViewModel mirip dengan MVC, Model-View Controller

Pengontrol diganti dengan ViewModel . ViewModel berada di bawah lapisan UI. ViewModel memperlihatkan data dan objek perintah yang dibutuhkan tampilan. Anda bisa menganggap ini sebagai objek kontainer yang dilihat untuk mendapatkan data dan tindakannya. ViewModel menarik datanya dari model.

Russel East membuat blog yang membahas lebih detail. Mengapa MVVM berbeda dari MVC

Untuk satu hal, MVVM adalah perkembangan dari pola MVC yang menggunakan XAML untuk menangani tampilan. Artikel ini menguraikan beberapa aspek dari keduanya.

Dorongan utama dari arsitektur Model / View / ViewModel tampaknya adalah bahwa di atas data ("Model"), ada lapisan lain dari komponen non-visual ("ViewModel") yang memetakan konsep-konsep data lebih dekat. untuk konsep tampilan data ("Tampilan"). Ini adalah ViewModel yang View terikat, bukan Model secara langsung.

Microsoft memberikan penjelasan tentang Pola MVVM di lingkungan Windows di sini .

Inilah bagian penting:

Dalam pola desain Model-View-ViewModel, aplikasi terdiri dari tiga komponen umum.

• Model : Ini mewakili model data yang dikonsumsi aplikasi Anda. Misalnya, dalam aplikasi berbagi gambar, lapisan ini mungkin mewakili set gambar yang tersedia pada perangkat dan API yang digunakan untuk membaca dan menulis ke perpustakaan gambar.

• Melihat : Aplikasi biasanya terdiri dari beberapa halaman UI. Setiap halaman yang ditampilkan kepada pengguna adalah tampilan dalam terminologi MVVM. Tampilan adalah kode XAML yang digunakan untuk mendefinisikan dan menata apa yang dilihat pengguna. Data dari model ditampilkan kepada pengguna, dan merupakan tugas ViewModel untuk memberi makan UI data ini berdasarkan kondisi aplikasi saat ini. Misalnya, dalam aplikasi berbagi gambar, tampilan akan menjadi UI yang menunjukkan kepada pengguna daftar album pada perangkat, gambar dalam album, dan mungkin yang lain yang menunjukkan gambar tertentu kepada pengguna.

• ViewModel : ViewModel mengikat model data, atau hanya model, ke UI, atau tampilan, aplikasi. Ini berisi logika yang digunakan untuk mengelola data dari model dan mengekspos data sebagai seperangkat properti yang dapat diikat oleh XAML UI, atau tampilan. Misalnya, dalam aplikasi berbagi gambar, ViewModel akan memaparkan daftar album, dan untuk setiap album memaparkan daftar gambar. UI adalah agnostik dari mana gambar berasal dan bagaimana mereka diambil. Ia hanya mengetahui seperangkat gambar yang diekspos oleh ViewModel dan menunjukkannya kepada pengguna.

Saya pikir salah satu perbedaan utama adalah bahwa dalam MVC, V Anda membaca M Anda secara langsung, dan melalui C untuk memanipulasi data, sedangkan di MVVM, VM Anda bertindak sebagai proxy M, serta menyediakan fungsionalitas yang tersedia untuk Anda. V.

Jika saya tidak penuh sampah, saya terkejut tidak ada yang membuat hibrida, di mana VM Anda hanyalah proxy M, dan C menyediakan semua fungsionalitas.

MVC adalah lingkungan yang terkendali dan MVVM adalah lingkungan yang reaktif.

Dalam lingkungan yang terkendali Anda harus memiliki lebih sedikit kode dan sumber logika yang umum; yang harus selalu hidup di dalam controller. Namun; di dunia web, MVC dengan mudah dibagi menjadi logika pembuatan view dan view dynamic logic. Penciptaan tinggal di server dan kehidupan dinamis di klien. Anda melihat ini banyak dengan ASP.NET MVC dikombinasikan dengan AngularJS sedangkan server akan membuat tampilan dan meneruskan Model dan mengirimkannya ke klien. Klien kemudian akan berinteraksi dengan View di mana AngularJS masuk sebagai pengendali lokal. Setelah diserahkan Model atau Model baru dilewatkan kembali ke pengontrol server dan ditangani. (Dengan demikian siklus terus berlanjut dan ada banyak terjemahan lain dari penanganan ini ketika bekerja dengan soket atau AJAX dll tetapi pada semua arsitekturnya identik.)

MVVM adalah lingkungan reaktif yang berarti Anda biasanya menulis kode (seperti pemicu) yang akan diaktifkan berdasarkan beberapa peristiwa. Dalam XAML, di mana MVVM tumbuh subur, ini semua mudah dilakukan dengan kerangka kerja penyatuan data bawaan TETAPI yang disebutkan ini akan bekerja pada sistem apa pun dalam Tampilan apa pun dengan bahasa pemrograman apa pun. Ini bukan MS spesifik. ViewModel menyala (biasanya properti berubah acara) dan View bereaksi terhadapnya berdasarkan pemicu apa pun yang Anda buat. Ini bisa menjadi teknis tetapi intinya adalah Tampilan stateless dan tanpa logika. Itu hanya mengubah status berdasarkan nilai-nilai. Selain itu, ViewModels adalah stateless dengan logika yang sangat sedikit, dan Model adalah negara dengan logika dasarnya nol karena mereka hanya harus mempertahankan keadaan. Saya menggambarkan ini sebagai keadaan aplikasi (Model), penerjemah negara (ViewModel), dan kemudian keadaan visual / interaksi (Tampilan).

Dalam aplikasi sisi desktop atau klien MVC Anda harus memiliki Model, dan Model harus digunakan oleh Pengendali. Berdasarkan Model, pengontrol akan mengubah tampilan. Tampilan biasanya terkait dengan Pengendali dengan Antarmuka sehingga Pengontrol dapat bekerja dengan berbagai Tampilan. Dalam ASP.NET logika untuk MVC sedikit mundur di server sebagai Pengontrol mengelola Model dan meneruskan Model ke Tampilan yang dipilih. View kemudian diisi dengan data berdasarkan model dan memiliki logikanya sendiri (biasanya set MVC lain seperti yang dilakukan dengan AngularJS). Orang-orang akan berdebat dan membuat ini bingung dengan aplikasi MVC dan mencoba melakukan keduanya pada titik pemeliharaan proyek yang pada akhirnya akan menjadi bencana. SELALU meletakkan logika dan kontrol di satu lokasi saat menggunakan MVC. JANGAN menulis logika tampilan di kode di belakang tampilan (atau di tampilan melalui JS untuk web) untuk mengakomodasi data Controller atau Model. Biarkan Pengontrol mengubah Tampilan. HANYA logika yang seharusnya hidup dalam Tampilan adalah apa pun untuk membuat dan menjalankan melalui Antarmuka yang digunakannya. Contohnya adalah mengirimkan nama pengguna dan kata sandi. Apakah desktop atau halaman web (pada klien) Pengendali harus menangani proses pengiriman setiap kali View mengaktifkan aksi Kirim. Jika dilakukan dengan benar, Anda selalu dapat menemukan jalan di sekitar web MVC atau aplikasi lokal dengan mudah. Apakah desktop atau halaman web (pada klien) Pengendali harus menangani proses pengiriman setiap kali View mengaktifkan aksi Kirim. Jika dilakukan dengan benar, Anda selalu dapat menemukan jalan di sekitar web MVC atau aplikasi lokal dengan mudah. Apakah desktop atau halaman web (pada klien) Pengendali harus menangani proses pengiriman setiap kali View mengaktifkan aksi Kirim. Jika dilakukan dengan benar, Anda selalu dapat menemukan jalan di sekitar web MVC atau aplikasi lokal dengan mudah.

MVVM secara pribadi adalah favorit saya karena sepenuhnya reaktif. Jika Model berubah, ViewModel mendengarkan dan menerjemahkan status itu dan hanya itu !!! View kemudian mendengarkan ViewModel untuk perubahan status dan juga pembaruan berdasarkan terjemahan dari ViewModel. Beberapa orang menyebutnya sebagai MVVM murni tetapi sebenarnya hanya ada satu dan saya tidak peduli bagaimana Anda memperdebatkannya dan itu selalu MVVM Murni di mana tampilan tersebut sama sekali tidak mengandung logika.

Berikut adalah sedikit contoh: Katakanlah Anda ingin memiliki slide menu pada tombol tekan. Di MVC Anda akan memiliki tindakan MenuPressed di antarmuka Anda. Pengontrol akan tahu kapan Anda mengklik tombol Menu dan kemudian memberi tahu Tampilan untuk meluncur di Menu berdasarkan metode Antarmuka lain seperti SlideMenuIn. Perjalanan pulang pergi untuk alasan apa? Jika Pengendali memutuskan Anda tidak bisa atau ingin melakukan sesuatu yang lain, itu sebabnya. Controller harus bertanggung jawab atas View dengan View tidak melakukan apa-apa kecuali Controller mengatakannya. NAMUN; dalam MVVM menu slide dalam animasi harus dibangun dan generik dan bukannya disuruh slide itu akan melakukannya berdasarkan beberapa nilai. Jadi ia mendengarkan ViewModel dan ketika ViewModel mengatakan, IsMenuActive = true (atau bagaimanapun) animasi untuk itu terjadi. Sekarang, dengan mengatakan bahwa saya ingin membuat poin lain BENAR-BENAR JELAS dan TOLONG perhatikan. IsMenuActive mungkin BAD MVVM atau desain ViewModel. Saat mendesain ViewModel Anda tidak boleh berasumsi bahwa View akan memiliki fitur sama sekali dan hanya melewati kondisi model yang diterjemahkan. Dengan begitu jika Anda memutuskan untuk mengubah Tampilan Anda untuk menghapus Menu dan hanya memperlihatkan data / opsi dengan cara lain, ViewModel tidak peduli. Jadi, bagaimana Anda mengelola Menu? Ketika data masuk akal itulah caranya. Jadi, salah satu cara untuk melakukan ini adalah memberi Menu daftar opsi (mungkin array dari ViewModels dalam). Jika daftar itu memiliki data, Menu kemudian tahu untuk membuka melalui pelatuk, jika tidak maka ia tahu untuk menyembunyikan melalui pelatuk. Anda cukup memiliki data untuk menu atau tidak di ViewModel. JANGAN memutuskan untuk menampilkan / menyembunyikan data itu di ViewModel .. cukup terjemahkan keadaan Model. Dengan cara ini, View sepenuhnya reaktif dan generik dan dapat digunakan dalam berbagai situasi.

Semua ini mungkin sama sekali tidak masuk akal jika Anda belum setidaknya sedikit terbiasa dengan arsitektur masing-masing dan mempelajarinya bisa sangat membingungkan karena Anda akan menemukan banyak BANYAK informasi di internet.

Jadi ... hal-hal yang perlu diingat untuk mendapatkan ini dengan benar. Putuskan di muka bagaimana merancang aplikasi Anda dan STICK TO IT.

Jika Anda melakukan MVC, yang hebat, maka pastikan Pengontrol Anda dapat diatur dan dalam kendali penuh atas Tampilan Anda. Jika Anda memiliki Tampilan yang besar, pertimbangkan untuk menambahkan kontrol ke Tampilan yang memiliki Pengontrol yang berbeda. JANGAN JANGAN membagi-bagikan pengontrol tersebut ke pengontrol lain. Sangat frustasi untuk dipertahankan. Luangkan waktu sejenak dan desain hal-hal secara terpisah dengan cara yang akan berfungsi sebagai komponen yang terpisah ... Dan selalu biarkan Pengendali memberitahu Model untuk melakukan atau bertahan penyimpanan. Pengaturan ketergantungan ideal untuk MVC di adalah View ← Controller → Model atau dengan ASP.NET (jangan mulai) Model ← View ↔ Controller → Model (di mana Model dapat sama atau Model yang sama sekali berbeda dari Controller ke View)... tentu saja satu-satunya yang perlu diketahui tentang Pengendali dalam Tampilan pada titik ini adalah sebagian besar untuk referensi titik akhir untuk mengetahui di mana kembali untuk lulus Model.

Jika Anda melakukan MVVM, saya memberkati jiwa baik Anda, tetapi luangkan waktu untuk melakukannya KANAN! Jangan gunakan antarmuka untuk itu. Biarkan Tampilan Anda memutuskan bagaimana tampilan berdasarkan nilai. Mainkan dengan View with Mock data. Jika pada akhirnya Anda memiliki Tampilan yang memperlihatkan kepada Anda Menu (seperti contohnya) meskipun Anda tidak menginginkannya pada saat itu, BAIK. Pandangan Anda berfungsi sebagaimana mestinya dan bereaksi berdasarkan nilai sebagaimana mestinya. Cukup tambahkan beberapa persyaratan lagi ke pemicu Anda untuk memastikan ini tidak terjadi ketika ViewModel berada dalam kondisi terjemahan tertentu atau perintah ViewModel untuk mengosongkan keadaan ini. Di Model ViewMU, JANGAN hapus ini dengan logika internal baik seolah-olah Anda memutuskan dari sana apakah tampilan akan melihatnya atau tidak. Ingat Anda tidak dapat berasumsi ada menu atau tidak di ViewModel. Dan akhirnya, Model seharusnya memungkinkan Anda untuk berubah dan kemungkinan besar kondisi toko. Di sinilah validasi dan semua akan terjadi; misalnya, jika Model tidak dapat memodifikasi keadaan maka hanya akan menandainya sendiri kotor atau semacamnya. Ketika ViewModel menyadari hal ini, ia akan menerjemahkan apa yang kotor, dan View akan menyadari hal ini dan menampilkan beberapa informasi melalui pemicu lain. Semua data di View dapat diikat ke ViewModel sehingga semuanya bisa dinamis hanya Model dan ViewModel sama sekali tidak tahu tentang bagaimana View akan bereaksi terhadap pengikatan. Faktanya Model tidak memiliki gagasan tentang ViewModel juga. Saat mengatur dependensi, mereka harus menunjuk seperti itu dan hanya suka saja t memodifikasi keadaan maka itu hanya akan menandakan dirinya kotor atau semacamnya. Ketika ViewModel menyadari hal ini, ia akan menerjemahkan apa yang kotor, dan View akan menyadari hal ini dan menampilkan beberapa informasi melalui pemicu lain. Semua data di View dapat diikat ke ViewModel sehingga semuanya bisa dinamis hanya Model dan ViewModel sama sekali tidak tahu tentang bagaimana View akan bereaksi terhadap pengikatan. Faktanya Model tidak memiliki gagasan tentang ViewModel juga. Saat mengatur dependensi, mereka harus menunjuk seperti itu dan hanya suka saja t memodifikasi keadaan maka itu hanya akan menandakan dirinya kotor atau semacamnya. Ketika ViewModel menyadari hal ini, ia akan menerjemahkan apa yang kotor, dan View akan menyadari hal ini dan menampilkan beberapa informasi melalui pemicu lain. Semua data di View dapat diikat ke ViewModel sehingga semuanya bisa dinamis hanya Model dan ViewModel sama sekali tidak tahu tentang bagaimana View akan bereaksi terhadap pengikatan. Faktanya Model tidak memiliki gagasan tentang ViewModel juga. Saat mengatur dependensi, mereka harus menunjuk seperti itu dan hanya suka saja Semua data di View dapat diikat ke ViewModel sehingga semuanya bisa dinamis hanya Model dan ViewModel sama sekali tidak tahu tentang bagaimana View akan bereaksi terhadap pengikatan. Faktanya Model tidak memiliki gagasan tentang ViewModel juga. Saat mengatur dependensi, mereka harus menunjuk seperti itu dan hanya suka saja Semua data di View dapat diikat ke ViewModel sehingga semuanya bisa dinamis hanya Model dan ViewModel sama sekali tidak tahu tentang bagaimana View akan bereaksi terhadap pengikatan. Faktanya Model tidak memiliki gagasan tentang ViewModel juga. Saat mengatur dependensi, mereka harus menunjuk seperti itu dan hanya suka sajaLihat → ViewModel → Model (dan catatan tambahan di sini ... dan ini mungkin akan diperdebatkan juga tetapi saya tidak peduli ... JANGAN LULUS MODEL ke VIEW kecuali MODEL itu tidak dapat diubah; jika tidak bungkuslah dengan ViewModel yang tepat. Tampilan seharusnya tidak melihat periode model. Saya memberikan demo tikus apa yang telah Anda lihat atau bagaimana Anda melakukannya, itu salah.)

Inilah tip terakhir saya ... Lihatlah aplikasi MVC yang dirancang dengan baik namun sangat sederhana dan lakukan hal yang sama untuk aplikasi MVVM. Satu akan memiliki kontrol lebih dengan fleksibilitas nol terbatas sementara yang lain tidak akan memiliki kontrol dan fleksibilitas tak terbatas.

Lingkungan yang terkontrol baik untuk mengelola seluruh aplikasi dari satu set pengontrol atau (satu sumber) sementara lingkungan yang reaktif dapat dipecah menjadi repositori yang terpisah dengan sama sekali tidak tahu apa yang sedang dilakukan aplikasi lainnya. Pengelolaan mikro vs manajemen gratis.

Jika saya tidak cukup bingung Anda mencoba menghubungi saya ... Saya tidak keberatan membahas ini dengan detail penuh dengan ilustrasi dan contoh.

Pada akhir hari kita semua programmer dan dengan itu anarki hidup di dalam kita ketika coding ... Jadi aturan akan dilanggar, teori akan berubah, dan semua ini akan berakhir babi mencuci ... Tapi ketika bekerja pada besar proyek dan tim besar, sangat membantu untuk menyetujui pola desain dan menegakkannya. Suatu hari nanti akan membuat langkah ekstra kecil yang diambil di awal menjadi lompatan dan batas penghematan nantinya.

Perbedaan Sederhana: (Terinspirasi oleh kursus Coursera AngularJS Yaakov)

MVC (Pengendali Tampilan Model)

1. Model: Model berisi informasi data. Tidak memanggil atau menggunakan Pengontrol dan Tampilan. Berisi logika bisnis dan cara-cara untuk merepresentasikan data. Beberapa data ini, dalam beberapa bentuk, dapat ditampilkan dalam tampilan. Itu juga bisa berisi logika untuk mengambil data dari beberapa sumber.
2. Pengendali: Bertindak sebagai koneksi antara view dan model. Lihat panggilan Kontroler dan Kontroler memanggil model. Ini pada dasarnya menginformasikan model dan / atau pandangan untuk mengubah yang sesuai.
3. Lihat: Penawaran dengan bagian UI. Berinteraksi dengan pengguna.

MVVM (Model View View Model)

ViewModel :

1. Ini adalah representasi dari keadaan pandangan.
2. Itu menyimpan data yang ditampilkan dalam tampilan.
3. Menanggapi untuk melihat acara, alias logika presentasi.
4. Memanggil fungsi lain untuk pemrosesan logika bisnis.
5. Tidak pernah secara langsung meminta tampilan untuk menampilkan sesuatu.

MVVM adalah penyempurnaan (dapat diperdebatkan) dari pola Presentation Model . Saya katakan masih bisa diperdebatkan, karena satu-satunya perbedaan adalah bagaimana WPF menyediakan kemampuan untuk melakukan pengikatan data dan penanganan perintah.

Model tampilan adalah model "abstrak" untuk elemen antarmuka pengguna Anda. Itu harus memungkinkan Anda untuk mengeksekusi perintah, dan tindakan dalam tampilan Anda dengan cara non-visual (misalnya untuk mengujinya).

Jika Anda telah bekerja dengan MVC, Anda mungkin menemukan sesuatu yang berguna untuk membuat objek model untuk mencerminkan keadaan tampilan Anda, misalnya, untuk menampilkan dan menyembunyikan beberapa dialog edit, dll. Dalam hal ini Anda menggunakan model viewm.

Pola MVVM hanyalah generalisasi dari praktik itu untuk semua elemen UI.

Dan ini bukan pola Microsoft, yang menambahkan bahwa binding data WPF / Silverlight sangat cocok untuk bekerja dengan pola ini. Tapi tidak ada yang menghentikan Anda untuk menggunakannya dengan wajah server java, misalnya.

Jawaban yang lain mungkin tidak mudah dimengerti bagi orang yang tidak terlalu terbiasa dengan subjek pola arsitektur. Seseorang yang baru mengenal arsitektur aplikasi mungkin ingin tahu bagaimana pilihannya dapat mempengaruhi aplikasinya dalam praktik dan apa yang terjadi di masyarakat.

Mencoba menjelaskan beberapa hal di atas, saya membuat skenario yang melibatkan MVVM, MVP, dan MVC ini. Kisah dimulai dengan pengguna mengklik tombol 'CARI' di aplikasi pencarian film ...:

Pengguna: Klik ...

Lihat : Siapa itu? [ MVVM | MVP | MVC ]

Pengguna: Saya baru saja mengklik tombol pencarian ...

Lihat : Oke, tunggu sebentar ... [ MVVM | MVP | MVC ]

( Lihat memanggil ViewModel | Presenter | Controller ...) [ MVVM | MVP | MVC ]

Lihat : Hey ViewModel | Presenter | Kontroler , Pengguna baru saja mengklik tombol pencarian, apa yang harus saya lakukan? [ MVVM | MVP | MVC ]

ViewModel | Presenter | Kontroler : Hai Lihat , apakah ada istilah pencarian di halaman itu? [ MVVM | MVP | MVC ]

Lihat : Ya, ... ini dia ... "piano" [ MVVM | MVP | MVC ]

—— Ini adalah perbedaan paling penting antara MVVM DAN MVP | MVC ———

Presenter : Terima kasih View ,… sementara itu saya mencari istilah pencarian pada Model , tolong tunjukkan padanya progress bar [ MVP | MVC ]

( Presenter | Controller memanggil Model ...) [ MVP | MVC ]

ViewController : Terima kasih, saya akan mencari istilah pencarian pada Model tetapi tidak akan memperbarui Anda secara langsung. Sebagai gantinya, saya akan memicu acara untuk mencariResultsListObservable jika ada hasilnya. Jadi Anda sebaiknya memperhatikan itu. [ MVVM ]

(Saat mengamati pemicu apa pun di searchResultsListObservable, View menganggap itu harus menampilkan beberapa progress bar untuk pengguna, karena ViewModel tidak akan berbicara dengannya tentang itu)

————————————————————————————

ViewModel | Presenter | Controller : Hey Model , Apakah Anda memiliki kecocokan untuk istilah pencarian ini ?: "piano" [ MVVM | MVP | MVC ]

Model : Hai ViewModel | Presenter | Kontroler , izinkan saya memeriksa ... [ MVVM | MVP | MVC ]

( Model membuat kueri ke basis data film ...) [ MVVM | MVP | MVC ]

( Setelah beberapa saat … )

———— Ini adalah titik divergen antara MVVM , MVP dan MVC ————–

Model : Saya menemukan daftar untuk Anda, ViewModel | Presenter , ini dia di JSON "[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993}]" [ MVVM | MVP ]

Model : Ada beberapa hasil yang tersedia, Pengendali. Saya telah membuat variabel bidang dalam contoh saya dan mengisinya dengan hasilnya. Nama itu adalah "searchResultsList" [ MVC ]

( Presenter | Controller terima kasih Model dan kembali ke View ) [ MVP | MVC ]

Presenter : Terima kasih telah menunggu Lihat , saya menemukan daftar hasil yang cocok untuk Anda dan mengaturnya dalam format yang rapi: [“Piano Teacher 2001 ″,” Piano 1993 ”]. Juga tolong sembunyikan bilah progres sekarang [ MVP ]

Pengendali : Terima kasih telah menunggu Lihat , saya telah bertanya Model tentang permintaan pencarian Anda. Ia mengatakan telah menemukan daftar hasil yang cocok dan menyimpannya dalam variabel bernama "searchResultsList" di dalam instance-nya. Anda bisa mendapatkannya dari sana. Harap sembunyikan bilah progres sekarang [ MVC ]

ViewModel : Pengamat apa pun di searchResultsListObservable diberitahu bahwa ada daftar baru ini dalam format yang rapi: [“Piano Teacher 2001 ″,” Piano 1993 ”]. [ MVVM ]

Lihat : Terima kasih banyak Presenter [ MVP ]

View : Terima kasih “ Controller ” [ MVC ] (Sekarang View mempertanyakan dirinya sendiri: Bagaimana saya harus menyajikan hasil yang saya dapatkan dari Model kepada pengguna? Haruskah tahun produksi film menjadi yang pertama atau terakhir ...?)

Lihat : Oh, ada pemicu baru di searchResultsListObservable ..., bagus, ada daftar yang rapi, sekarang saya hanya perlu menunjukkannya dalam daftar. Saya juga harus menyembunyikan bilah progres sekarang karena saya sudah mendapatkan hasilnya. [ MVVM ]

Jika Anda tertarik, saya telah menulis serangkaian artikel di sini , membandingkan MVVM, MVP dan MVC dengan menerapkan aplikasi android pencarian film.

Menyuntikkan ViewModels yang sangat diketik ke dalam View menggunakan MVC

1. Pengontrol bertanggung jawab untuk mengaktifkan ViewModel dan menyuntikkannya ke dalam Tampilan. (untuk mendapatkan permintaan)
2. ViewModel adalah wadah untuk DataContext dan kondisi tampilan seperti item yang dipilih terakhir dll.
3. Model berisi entitas DB dan sangat dekat dengan Skema DB yang melakukan kueri dan penyaringan. (Saya suka EF dan LINQ untuk ini)
4. Model juga harus mempertimbangkan repositori dan atau proyeksi hasil ke dalam tipe yang kuat (EF memiliki metode yang bagus ... EF.Database.Select (querystring, parms) untuk akses ADO langsung untuk menyuntikkan pertanyaan dan mendapatkan kembali tipe yang kuat. Ini membahas EF argumen lambat. EF TIDAK SLOW !
5. ViewModel mendapatkan data dan melakukan aturan dan validasi bisnis
6. Pengontrol pada posting kembali akan cal metode ViewModel Post dan menunggu hasil.
7. Controller akan menyuntikkan Viewmodel yang baru diperbarui ke View. View hanya menggunakan tipe binding yang kuat .
8. Tampilan hanya membuat data, dan memposting acara kembali ke controller. (lihat contoh di bawah)
9. MVC memotong permintaan masuk dan mengarahkannya ke pengontrol yang tepat dengan tipe data yang kuat

Dalam model ini tidak ada lagi kontak tingkat HTTP dengan objek permintaan atau respons ketika mesin MVC MSFT menyembunyikannya dari kami.

Dalam klarifikasi butir 6 di atas (atas permintaan) ...

Asumsikan ViewModel seperti ini:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

Metode pengontrol posting akan terlihat seperti ini (Lihat di bawah), perhatikan bahwa instance mvm secara otomatis di-instanciated oleh mekanisme pengikatan MVC. Anda tidak perlu turun ke lapisan string kueri sebagai hasilnya! Ini adalah MVC instantiating ViewModel untuk Anda berdasarkan string kueri!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

Perhatikan bahwa agar metode tindakan di atas berfungsi sesuai keinginan Anda, Anda harus memiliki CTOR nol yang ditetapkan yang menginternalisasi hal-hal yang tidak dikembalikan dalam pos. Posting kembali juga harus memposting nama belakang / pasangan nilai untuk hal-hal yang berubah. Jika ada pasangan nama / nilai yang hilang, mesin penjilidan MVC melakukan hal yang benar yang tidak ada artinya! Jika ini terjadi, Anda mungkin mendapati diri Anda berkata "Saya kehilangan data di bagian belakang" ...

Keuntungan dari pola ini adalah ViewModel melakukan semua "kekacauan" pekerjaan interfacing ke logika Model / Buisness, controller hanyalah semacam router. Ini adalah SOC dalam aksi.

MVVM menambahkan model tampilan ke dalam campuran. Ini penting, karena memungkinkan Anda untuk menggunakan banyak pendekatan pengikatan WPF, tanpa menempatkan semua potongan khusus UI dalam model reguler Anda.

Saya mungkin salah, tapi saya tidak yakin MVVM benar-benar memaksa pengontrol ke dalam campuran. Saya menemukan konsepnya lebih sejalan dengan: http://martinfowler.com/eaaDev/PresentationModel.html . Saya pikir orang-orang memilih untuk menggabungkannya dengan MVC, bukan karena itu dimasukkan ke dalam pola.

Dari apa yang saya tahu, peta MVVM ke MV MVC - yang berarti bahwa dalam pola MVC tradisional, V tidak berkomunikasi langsung dengan M. Dalam versi kedua MVC, ada hubungan langsung antara M dan V. MVVM tampaknya mengambil semua tugas yang terkait dengan komunikasi M dan V, dan memasangkannya untuk memisahkannya dari C. Akibatnya, masih ada alur kerja aplikasi lingkup yang lebih besar (atau implementasi skenario penggunaan) yang tidak sepenuhnya diperhitungkan dalam MVVM. Ini adalah peran dari pengontrol. Dengan menghapus aspek tingkat yang lebih rendah dari pengontrol, mereka lebih bersih dan membuatnya lebih mudah untuk memodifikasi skenario penggunaan aplikasi dan logika bisnis, juga membuat pengontrol lebih dapat digunakan kembali.

Itu mengejutkan saya bahwa ini adalah jawaban yang sangat banyak dipilih tanpa menyebutkan asal MVVM. MVVM adalah istilah populer yang digunakan dalam komunitas Microsoft dan berasal dari Model Presentasi Martin Fowler . Jadi untuk memahami motif pola dan perbedaan dengan yang lain, artikel asli tentang pola adalah hal pertama yang dibaca.

Yah, umumnya MVC digunakan dalam pengembangan Web dan MVVM paling populer dalam pengembangan WPF / Silverlight. Namun, kadang-kadang arsitek web mungkin memiliki campuran MVC dan MVVM.

Misalnya: Anda mungkin menggunakan knockout.js dan dalam hal ini Anda akan memiliki MVVM di sisi klien Anda. Dan sisi server MVC Anda juga dapat berubah. Dalam aplikasi yang kompleks, tidak ada yang menggunakan Model murni. Mungkin memiliki rasa untuk menggunakan ViewModel sebagai "Model" MVC dan Model asli Anda pada dasarnya akan menjadi bagian dari VM ini. Ini memberi Anda lapisan abstraksi ekstra.

MVVMC, atau mungkin MVC +, tampaknya menjadi pendekatan yang layak untuk perusahaan serta pengembangan aplikasi yang cepat. Meskipun baik untuk memisahkan UI dari logika bisnis dan interaksi, pola MVVM 'murni' dan sebagian besar contoh yang tersedia berfungsi paling baik pada tampilan tunggal.

Tidak yakin tentang desain Anda, tetapi sebagian besar aplikasi saya, bagaimanapun, mengandung halaman dan beberapa tampilan (dapat digunakan kembali) dan dengan demikian ViewModels perlu berinteraksi sampai batas tertentu. Menggunakan halaman sebagai pengontrol akan mengalahkan tujuan MVVM sama sekali, jadi tidak menggunakan pendekatan "VM-C" untuk logika yang mendasari dapat mengakibatkan .. well .. konstruksi yang menantang saat aplikasi matang. Bahkan di VB-6 kebanyakan dari kita mungkin berhenti mengkodekan logika bisnis ke peristiwa Button dan mulai 'menyampaikan' perintah ke controller, kan? Baru-baru ini saya melihat banyak bingkai yang muncul pada topik itu; favorit saya jelas adalah pendekatan Magellan (at codeplex). Selamat coding!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

Controller tidak digantikan oleh ViewModel di MVVM, karena ViewModel memiliki fungsi yang sama sekali berbeda dengan Controller. Anda masih memerlukan Controller, karena tanpa Controller Model Anda, ViewModel dan View tidak akan berbuat banyak ... Di MVVM Anda juga memiliki Controller, nama MVVM hanya menyesatkan.

MVVMC adalah nama yang tepat menurut pendapat saya.

Seperti yang Anda lihat, ViewModel hanyalah tambahan untuk pola MVC. Ini memindahkan konversi-logika (misalnya mengonversi objek ke string) dari Controller ke ViewModel.

Saya membuat artikel Sedang untuk ini.

MVVM

1. Lihat ➡ Model ViewModel ➡

   • Tampilan memiliki referensi ke ViewModel tetapi tidak sebaliknya.
   • ViewModel memiliki referensi ke Model tetapi tidak sebaliknya.
   • Tampilan tidak memiliki referensi ke Model dan sebaliknya.

2. Jika Anda menggunakan controller, ia dapat memiliki referensi ke Views dan ViewModels , meskipun Controller tidak selalu diperlukan seperti yang ditunjukkan dalam SwiftUI .

3. Binding Data : kami membuat pendengar untuk ViewModel Properties.

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

perbedaan pengaturan

1. Logika bisnis diadakan di pengontrol untuk MVC dan ViewModels untuk MVVM.
2. Acara diteruskan langsung dari View ke controller di MVC sementara acara dilewatkan dari View ke ViewModel ke Controller (jika ada) untuk MVVM.

Fitur umum

1. Baik MVVM dan MVC tidak memungkinkan View untuk mengirim pesan langsung ke Model / s.
2. Keduanya memiliki model.
3. Keduanya memiliki pandangan.

Keuntungan MVVM

1. Karena ViewModels memiliki logika bisnis, mereka adalah objek konkret yang lebih kecil yang membuatnya mudah untuk disatukan. Di sisi lain, di MVC, logika bisnis ada di ViewController. Bagaimana Anda bisa percaya bahwa uji unit pengontrol tampilan secara komprehensif aman tanpa menguji semua metode dan pendengar secara bersamaan? Anda tidak dapat sepenuhnya mempercayai hasil tes unit.
2. Dalam MVVM, karena logika bisnis disedot keluar dari Controller ke unit ViewModel atom, ukuran ViewController menyusut dan ini membuat kode ViewController lebih terbaca.

Keuntungan MVC

1. Menyediakan logika bisnis di dalam pengontrol mengurangi kebutuhan percabangan dan oleh karena itu pernyataan lebih cenderung dijalankan pada cache yang lebih berkinerja tinggi daripada merangkum logika bisnis ke dalam ViewModels.
2. Menyediakan logika bisnis di satu tempat dapat mempercepat proses pengembangan untuk aplikasi sederhana, di mana tes tidak diperlukan. Saya tidak tahu kapan tes tidak diperlukan.
3. Memberikan logika bisnis di ViewController lebih mudah dipikirkan oleh pengembang baru.

Dari sudut pandang praktis, MVC (Model-View-Controller) adalah sebuah pola. Namun, MVC ketika digunakan sebagai ASP.net MVC, ketika dikombinasikan dengan Entity Framework (EF) dan "alat-alat listrik" adalah pendekatan yang sangat kuat dan terotomatisasi sebagian untuk membawa basis data, tabel, dan kolom ke halaman web, baik secara penuh Operasi CRUD atau operasi R (Retrieve atau Read) saja. Setidaknya ketika saya menggunakan MVVM, View Models berinteraksi dengan model yang bergantung pada objek bisnis, yang pada gilirannya "buatan tangan" dan setelah banyak upaya, orang beruntung mendapatkan model sebaik apa yang diberikan EF "keluar". -dari-kotak ". Dari sudut pandang pemrograman praktis, MVC tampaknya pilihan yang baik karena memberikan banyak utilitas out-of-box, tetapi masih ada potensi untuk ditambahkan bells and whistles.

Sebagai pelengkap dari banyak respons yang diberikan, saya ingin menambahkan beberapa perspektif tambahan dari web sisi klien Modern - atau sudut pandang Aplikasi Web Kaya .

Memang hari ini situs web sederhana dan aplikasi web yang lebih besar biasanya dibangun dengan banyak perpustakaan populer seperti Bootstrap. Dibangun oleh Steve Sanderson, Knockout menyediakan dukungan untuk pola MVVM yang meniru salah satu perilaku paling penting dalam pola: pengikatan data melalui View Model. Dengan sedikit JavaScript, data dan logika dapat diimplementasikan yang kemudian dapat ditambahkan ke elemen halaman dengan data-bindatribut HTML sederhana , mirip dengan menggunakan banyak fitur Bootstrap . Bersama-sama, kedua perpustakaan ini sendiri menawarkan konten interaktif; dan ketika dikombinasikan dengan perutean pendekatan ini dapat menghasilkan pendekatan yang sederhana namun kuat untuk membangun Aplikasi Halaman Tunggal .

Demikian pula, kerangka kerja sisi klien modern seperti Angular mengikuti pola MVC dengan konvensi, tetapi juga menambahkan Layanan. Menariknya, ini disebut-sebut sebagai Model-View-Apapun (MVW). (Lihat posting ini di Stack Overflow .)

Selain itu, dengan munculnya kerangka kerja web Progresif seperti Angular 2, kami melihat perubahan dalam terminologi dan mungkin pola arsitektur baru di mana Komponen terdiri dari Tampilan atau Templat dan berinteraksi dengan Layanan - yang semuanya dapat dimuat dalam Modul; dan serangkaian Modul membuat aplikasi.

Dulu saya berpikir bahwa MVC dan MVVM adalah sama. Sekarang karena keberadaan Flux saya dapat membedakannya:

Di MVC, untuk setiap tampilan di aplikasi Anda, Anda memiliki model dan pengontrol, jadi saya akan menyebutnya view, view model, view controller. Pola tidak memberi tahu Anda bagaimana satu tampilan dapat berkomunikasi dengan yang lain. Oleh karena itu, dalam kerangka kerja yang berbeda ada implementasi yang berbeda untuk itu. Misalnya ada implementasi di mana pengontrol berbicara satu sama lain sedangkan di implementasi lain ada komponen lain yang menjadi penengah di antara mereka. Bahkan ada implementasi di mana model tampilan berkomunikasi satu sama lain, yang merupakan pemutusan pola MVC karena model tampilan hanya dapat diakses oleh pengontrol tampilan.

Di MVVM, Anda juga memiliki model tampilan untuk setiap komponen. Pola tidak menentukan bagaimana tampilan hen harus mempengaruhi model tampilan, jadi biasanya sebagian besar kerangka kerja hanya menyertakan fungsionalitas pengontrol dalam model tampilan. Namun, MVVM memberi tahu Anda bahwa data model tampilan Anda harus berasal dari model, yang merupakan keseluruhan model yang tidak disadari atau dikustomisasi ke tampilan tertentu.

Untuk menunjukkan perbedaannya, mari kita ambil pola Flux. Pola fluks memberi tahu bagaimana pandangan berbeda dalam aplikasi harus berkomunikasi. Setiap tampilan mendengarkan toko dan melakukan aksi menggunakan dispatcher. Dispatcher pada gilirannya memberi tahu semua toko tentang tindakan yang baru saja dilakukan, dan toko memperbarui sendiri. Toko di Flux sesuai dengan model (umum) di MVVM. itu tidak khusus untuk tampilan tertentu. Jadi biasanya ketika orang menggunakan React dan Flux, setiap komponen React sebenarnya mengimplementasikan pola MVVM. Ketika suatu tindakan terjadi, model tampilan memanggil dispatcher, dan akhirnya itu diperbarui sesuai dengan perubahan di toko, yang merupakan model. Anda tidak bisa mengatakan bahwa setiap komponen mengimplementasikan MVC karena dalam MVC hanya controller yang dapat memperbarui model tampilan.

mvc adalah sisi server dan mvvm adalah sisi klien (browser) dalam pengembangan web.

sebagian besar waktu javascript digunakan untuk mvvm di browser. ada banyak teknologi sisi server untuk MVC.

Singkatnya, MVC Controler mengetahui (kontrol) tampilan, sedangkan di MVVM, ViewModel tidak mengetahui siapa yang mengkonsumsinya. ViewModel memperlihatkan properti dan tindakan yang dapat diamati kepada siapa pun yang mungkin tertarik menggunakannya. Fakta itu membuat pengujian lebih mudah karena tidak ada referensi ke UI dalam ViewModel.

Model – View – Controller (biasanya dikenal sebagai MVC ) adalah pola desain perangkat lunak yang biasanya digunakan untuk mengembangkan antarmuka pengguna yang membagi logika program terkait menjadi tiga elemen yang saling berhubungan. Hal ini dilakukan untuk memisahkan representasi informasi internal dari cara informasi disajikan dan diterima oleh pengguna. Mengikuti pola arsitektur MVC memisahkan komponen-komponen utama ini yang memungkinkan penggunaan kembali kode dan pengembangan paralel.

Secara tradisional digunakan untuk antarmuka pengguna grafis desktop (GUI), pola ini telah menjadi populer untuk merancang aplikasi web. Bahasa pemrograman populer seperti JavaScript, Python, Ruby, PHP, Java, dan C # memiliki kerangka kerja MVC yang digunakan dalam pengembangan aplikasi web langsung dari kotak.

Model

Komponen utama dari pola. Ini adalah struktur data dinamis aplikasi, independen dari antarmuka pengguna. Secara langsung mengelola data, logika, dan aturan aplikasi.

Melihat

Representasi informasi seperti grafik, diagram, atau tabel. Beberapa tampilan dari informasi yang sama dimungkinkan, seperti bagan batang untuk manajemen dan tampilan tabular untuk akuntan.

Pengendali

Menerima input dan mengubahnya menjadi perintah untuk model atau tampilan.

Selain membagi aplikasi ke dalam komponen-komponen ini, desain model-view-controller mendefinisikan interaksi di antara mereka.

Model bertanggung jawab untuk mengelola data aplikasi. Ini menerima input pengguna dari controller.

Tampilan berarti presentasi model dalam format tertentu.

Pengontrol merespons input pengguna dan melakukan interaksi pada objek model data. Pengontrol menerima input, secara opsional memvalidasi dan kemudian meneruskan input ke model.

Model – View – ViewModel (MVVM) adalah pola arsitektur perangkat lunak.

MVVM memfasilitasi pemisahan pengembangan antarmuka pengguna grafis - baik itu melalui bahasa markup atau kode GUI - dari pengembangan logika bisnis atau logika back-end (model data). Model tampilan MVVM adalah konverter nilai, yang berarti model tampilan bertanggung jawab untuk mengekspos (mengkonversi) objek data dari model sedemikian rupa sehingga objek mudah dikelola dan disajikan. Dalam hal ini, model tampilan lebih dari model tampilan dan menangani sebagian besar jika tidak semua logika tampilan. Model tampilan dapat menerapkan pola mediator, mengatur akses ke logika back-end di sekitar set kasus penggunaan yang didukung oleh tampilan.

MVVM adalah variasi dari pola desain Presentation Model Martin Fowler. MVVM mengabstraksi kondisi tampilan dan perilaku dengan cara yang sama, tetapi Model Presentasi mengabstraksi tampilan (membuat model tampilan) dengan cara yang tidak bergantung pada platform antarmuka pengguna tertentu.

MVVM diciptakan oleh arsitek Microsoft, Ken Cooper dan Ted Peters secara khusus untuk menyederhanakan pemrograman yang digerakkan oleh antarmuka pengguna. Pola ini dimasukkan ke dalam Windows Presentation Foundation (WPF) (sistem grafis .NET Microsoft) dan Silverlight (turunan aplikasi Internet WPF). John Gossman, salah satu arsitek WPF dan Silverlight Microsoft, mengumumkan MVVM di blog-nya pada 2005.

Model – View – ViewModel juga disebut sebagai model-view-binder, terutama dalam implementasi yang tidak melibatkan platform .NET. ZK (kerangka kerja aplikasi web yang ditulis dalam Java) dan KnockoutJS (pustaka JavaScript) menggunakan model-view-binder.