Apa perbedaan antara MVC dan MVVM? [Tutup]


1312

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


54
Perhatikan bahwa sementara MVVM diciptakan oleh Microsoft, banyak pengembang dan proyek non-Microsoft telah mulai mengadopsi pola ini. Komentar ini dibawakan oleh departemen pembenci MS.
BoltClock

1
Setelah bekerja dengan MVVM untuk waktu yang lama, sikat pertama saya dengan MVC membuat frustrasi, sampai saya tahu saya bisa meneruskan ViewModels bolak-balik ke browser menggunakan teknik penjilidan yang ditemukan di MVVM. Tetapi seperti yang dikatakan Joel di atas, satu-satunya cara untuk mendapatkan status kembali dari browser adalah dengan memposting perubahan dalam bentuk (yang menggunakan nama / nilai) berpasangan. Jika Anda tidak memahami hal ini dengan baik. Anda akan mengalami kesulitan di MVC. Lihat saja pengontrol sebagai penyuntik ketergantungan untuk tampilan dan Anda siap.
John Peters

2
Pertanyaan terbalik tentang [pola desain] tingkat tinggi. Saya ingin menyarankan penggunaan diagram pada jawaban.
Ricardo


1
Berbeda dengan metode MVC, ViewModel bukan pengontrol. Ini bukan bertindak sebagai pengikat yang mengikat data antara tampilan dan model. Sementara format MVC dirancang khusus untuk menciptakan pemisahan kekhawatiran antara model dan tampilan, format MVVM dengan pengikatan data dirancang khusus untuk memungkinkan tampilan dan model untuk berkomunikasi langsung satu sama lain. hackernoon.com/...
blueray

Jawaban:


684

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.


8
@ Thomas Zielinski: Benar, tetapi "di mana mereka digunakan" bukan pertanyaan (atau titik jawaban saya). Maksud saya adalah bahwa pengontrol masih berguna dalam MVVM.
Hilang Coding

58
Saya setuju. Komentar saya disebabkan oleh pencerahan yang tiba-tiba dan bukan karena saya tidak setuju dengan Anda.
Tomasz Zieliński

Kami juga menggunakan pengontrol untuk mengontrol "aliran" tampilan di UI seperti penyihir.
riezebosch

3
@ Justin: Saya melihat kata-kata saya dari kalimat itu sedikit ambigu. Sebenarnya saya maksud pengujian unit untuk semua komponen lebih mudah didukung, tidak khusus hanya meningkatkan pengujian ViewModels (yang seperti yang Anda sebutkan tidak benar-benar melakukan banyak hal di MVCVM ... yang memang Anda inginkan). Manfaat nyata dari pengontrol adalah Anda benar-benar menghapus sebagian besar persyaratan untuk pengujian dari ViewModel (di mana orang terus mendorong logika pengontrol) dan meletakkannya di tempat yang dapat diuji (terutama Pengontrol dan Model). Komentar penggunaan kembali khusus untuk VM dalam kalimat itu. Saya sudah mengeditnya.
Hilang Coding

7
@TomaszZielinski M (MVVM) C
Mohamed Emad

274

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.

 


47
MVC tidak berasal dari web. Trygve Reenskaug memperkenalkan MVC ke Smalltalk-76 pada 1970-an.
Arialdo Martini

11
Bahkan jika diubah menjadi "MVC dipopulerkan melalui desain aplikasi web." Saya berpendapat bahwa ini adalah spekulasi tanpa kutipan yang tepat.
Dan Bechard

4
Arialdo: Terima kasih, saya tidak tahu tentang Smalltalk-76. (Dimainkan dengan mainan lain waktu itu.) Lelucon, menarik berapa umur dari beberapa konsep ini. - @Dan, apa yang saya tulis adalah: "[MVC] mungkin sudah ada sebelum [web], tetapi web adalah bagaimana ia dipopulerkan ke massa pengembang web." Saya masih berpikir itu benar. Saya tidak memiliki kutipan untuk itu, tapi kemudian saya merasa saya tidak perlu mengutipnya karena mempopulerkan massa MVC itu adalah bagian dari pengalaman pribadi saya ketika saya mulai sebagai pengembang web pada awal dekade terakhir. Apache Struts sedang populer saat itu, dengan banyak kacang untuk MVC.
Lumi

5
MVC bukan "komunikasi satu arah" pada dasarnya karena peramban selalu menerbitkan Gets and Posts. Baik Mendapat dan Posting dapat mengubah nilai bidang yang ditemukan di string kueri. Ini memberi browser kesempatan yang luas untuk mengirim informasi kembali ke controller. MVC dibangun di atas HTTP 1.0 yang selalu memiliki komunikasi dua arah.
John Peters

13
Terima kasih Lumi. Bagi saya ini jauh lebih masuk akal daripada jawaban lainnya. Apakah itu benar? Saya tidak punya ide. Tetapi dari sudut pandang saya itu setidaknya masuk akal.
gcdev

175

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


81
Kalimat "Pengontrol diganti dengan Model Tampilan" tidak benar. Dalam MVVM apa peran controller adalah penyatuan data (atau mengikat dengan konvensi jika Anda menggunakannya).
DaniCE

9
MVVM hanya akan masuk akal ketika menggunakan pengikatan data dua arah WPF. Kalau tidak, MVC / MVP dll akan cukup.
Jeff

266
@DaniCE: Josh Smith:If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. …
sll

7
@OmShankar Tanggal 11 bukan dari dirimu sendiri Ada 10 total orang, dan 12 total opini. Pepatah ini dimaksudkan untuk menyiratkan bahwa definisi pola-pola ini sangat terbuka untuk interpretasi bahwa setidaknya dua orang akan cukup bingung untuk memiliki lebih dari satu pendapat.
Dan Bechard

7
@DaniCE Nah ini sebenarnya titik pengikatan data WPF, dan Microsoft menemukan MVVM, di mana orang dapat memotong controller sepenuhnya, (mengklaim kalimat "Controller sedang diganti dengan View Model" menjadi tidak benar hanya karena ada pengontrol di belakang layar, pada dasarnya seperti mengklaim pernyataan "Bahasa tingkat tinggi menggantikan penggunaan kode mesin samar dengan yang lebih mudah dibaca" menjadi salah karena di belakang layar bahasa mesin masih digunakan ...)
yoel halb

91

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.


20
Saya pikir paragraf yang Anda kutip merangkum dengan baik IMHO. Aspek dari ViewModel adalah bahwa itu adalah versi yang diratakan / diubah model untuk tampilan. Banyak pola MV * lainnya mengikat model yang sebenarnya .
Daniel Auger

1
"Banyak pola MV * lainnya mengikat model yang sebenarnya"? Benarkah? Saya pikir pandangan selalu seharusnya mengikat ke controller di MVC, tidak peduli apa.
PlagueHammer

9
Nocturne: Dalam MVC klasik, View tidak banyak berhubungan dengan controller, sebagian besar terikat ke Model. Anggap saja sebagai robot - Model mewakili posisi sendi robot, View adalah monitor LCD di mana Anda melihat robot, Pengendali misalnya keyboard. Dalam pengaturan seperti itu, Tampilan tergantung pada Model, yaitu posisi spasial robot, yang dapat Anda lihat di monitor adalah representasi langsung Model.
Tomasz Zieliński

@Nocturne Apa yang muncul daniel katakan adalah bahwa sementara secara resmi semua MV * harus menggunakan VM terpisah, banyak pengembang mengabaikannya, dan meneruskan model yang sebenarnya, dan pada kenyataannya tidak ada dalam spesifikasi seperti MVC yang tidak mengizinkannya, namun dalam MVVM one harus ada VM yang bertanggung jawab atas transisi antara model dan tampilan
yoel halb

Saya akan mengatakannya seperti ini: Modelnya adalah lemari untuk skema DB. Ketika kueri dijalankan, ia dapat memproyeksikan data ke tipe yang kuat pada lapisan model. Viewmodel adalah koleksi benda, termasuk objek model, tetapi bisa dan memang menahan kondisi tampilan sehubungan dengan data. Pengontrol hanyalah polisi lalu lintas antara model tampilan dan tampilan dan tentu saja tampilan hanya berkaitan dengan status tampilan.
John Peters

52

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. masukkan deskripsi gambar di sini

  • 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.


7
Perhatikan bahwa walaupun artikel yang dirujuk berlaku untuk pengembangan dengan Microsoft Stack - Khususnya Windows Phone - dan XAML, itu tidak harus terjadi.
Richard Nalezynski

Jawaban ini menyoroti masalah dengan nama "MVVM" - seharusnya "VVMM" atau "MVMV" - MV-VM memiliki hubungan yang sepenuhnya salah!
Etherman

45

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.


1
+1. Istilahnya adalah yang benar saya pikir. tetapi tentang membuat hybrid M-MProxy-VC bukankah itu terlalu banyak pemisahan? saya pikir itu akan cukup menggunakan MVC sedangkan M adalah Model dengan dukungan penuh dari Binding. ;)
ktutnik

2
+1. Seperti yang saya komentari di atas, saya berpikir bahwa MVC digunakan untuk merancang seluruh aplikasi (web), sementara MVVM digunakan di dalam komponen View dari MVC.
Tomasz Zieliński

23
@ktutnik: Model biasanya duduk di server, sedangkan ViewModel tinggal di klien. Jadi tidak layak bagi HTML untuk mengikat langsung ke Model sisi server. Oleh karena itu kita membutuhkan ModelView yang bertindak sebagai set data kerja lokal yang belum disimpan yang diekstraksi dari model menggunakan misalnya AJAX / JSON.
Tomasz Zieliński

1
Tampilan memang "membaca" data model karena sudah diletakkan di sana oleh controller. Saya suka menyebutnya sebagai "injeksi data" oleh controller karena itu benar-benar controller yang bertanggung jawab. Semua pandangan dalam acara membuat dan api dalam pikiran saya.
John Peters

3
Saya minta maaf tetapi tidak setuju dengan interpretasi MVVM. ViewModel tidak tahu tentang Tampilan atau seperti apa Tampilan itu atau bagaimana responsnya dan Model juga tidak tahu model ViewModel. Bahkan, sebuah View bahkan tidak harus tahu tentang Model, hanya sebuah ViewModel. Model harus merepresentasikan data dan status aplikasi, ViewModel harus menerjemahkan status ke data yang mampu UI (saya sarankan semua primitif pada titik ini) dan View harus bereaksi terhadap terjemahan ViewModels. Data akan sering sama tetapi masih harus dibungkus dan dikirim kembali melalui Model View dan tidak ada pengendali.
Michael Puckett II

24

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.


Jawaban yang luar biasa terperinci dan akurat! Membuatnya sejernih kristal untuk saya. :-)
ankush981

"Mempelajari itu bisa sangat membingungkan karena kamu akan menemukan BANYAK BURUK informasi di internet." Ya. Sebagai seseorang yang tampaknya memiliki banyak pengalaman dengan pola desain ini, apakah Anda tahu tutorial / panduan yang bagus?
MarredCheese

1
Sejujurnya, pengetahuan MVVM saya telah melalui bertahun-tahun atau coba-coba dan menggunakan / melakukan berbagai cara berdasarkan upaya tim. Saya baru-baru ini (2 tahun yang lalu) mampu memasukkan pengalaman saya sendiri ke dalam rencana permainan yang dirangkum dan memimpin tim untuk menyelesaikannya dan kami sangat sukses. Yang mengatakan, saya tidak bisa mengarahkan Anda ke satu tempat dan meminta maaf. Saya dapat mengatakan bahwa Anda benar, karena berbagai pendapat itu sangat membingungkan tetapi, IMO, dengan MVVM itu harus menjadi generik mungkin. Jadikan ViewModels mampu memungkinkan pandangan untuk mengikat dan bekerja dengan data secara ketat tetapi untuk tampilan APAPUN ...
Michael Puckett II

1
Dengan kata lain JANGAN PERNAH membuat ViewModel menganggap Tampilan akan terlihat atau bertindak dengan cara apa pun. ViewModel, bagi saya, paling baik digunakan seperti API, tetapi dengan komunikasi yang ketat. Ikuti rencana permainan untuk mengikat, mengedit, memerintah, dll. Jika Lihat membutuhkan logika tambahan untuk berfungsi dengan cara tertentu, itu tidak ada hubungannya dengan aplikasi atau data (seperti animasi atau kotak dropdown ..) maka logika itu termasuk dalam tier Lihat di suatu tempat entah bagaimana. Sekali lagi, ada banyak pendapat dan ini hanya milik saya, tetapi saya memiliki latar belakang yang kuat di sini dan rekam jejak yang solid sejauh ini.
Michael Puckett II

Saya punya contoh aplikasi yang saya tidak suka berbagi dan atau tidak keberatan membuat acara sederhana dan memberi tahu Anda atau siapa pun jika ingin atau ingin tahu.
Michael Puckett II

23

Perbedaan Sederhana: (Terinspirasi oleh kursus Coursera AngularJS Yaakov)

masukkan deskripsi gambar di sini

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.

18

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.


1
Pada tahun 2009 jawaban ini mungkin bagus, tetapi hari ini, tidak ada perdebatan karena bahkan kontrol HTML Helper dari MSFT memungkinkan untuk mengikat menggunakan pembantu "Untuk" yang terkenal itu. Knockout adalah semua tentang pengikatan data di sisi klien.
John Peters

1
Saya menyatakan ini, pada tahun 2009, karena terlalu banyak orang di komunitas menerima jawaban ini. Saya bilang itu bisa diperdebatkan, karena MVVM dan Model Presentasi benar-benar memiliki pola yang sama dengan nama yang berbeda. Tank untuk popularitas di WPF, ini sering disebut MVVM dalam kerangka kerja lain hari ini, tetapi kedua nama itu akurat.
wekempf

15

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.


13

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.


Ada jawaban yang bagus di bawah semua teks rasa di sini ... Dengan beberapa format dan membuang obrolan ringan antar komponen, ini bisa menjadi yang terbaik di halaman ini.
neonblitzer

10

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.


Bisakah Anda memperjelas item 6? Saya menyadari Anda hanya mencakup ASP.Net, tetapi tampaknya menambahkan ketergantungan yang tidak diinginkan ke ViewModel. (misalnya pengetahuan dari mana data berasal / pergi ke). Contoh kode (kode semu?) Akan baik untuk memperjelas jawaban ini dan menunjukkan bagian mana yang merupakan sisi server dan mana yang sisi klien.
Hilang Coding

9

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.


3
MVVM, sebenarnya, adalah Model Presentasi, meskipun MVVM menjadi nama yang lebih disukai untuk realisasi spesifik WPF dari pola.
wekempf

Sepakat. The Viewmodel di MVC "IS" mesin negara untuk tampilan. Ini berisi datacontext dan melacak semua informasi item yang dipilih serta dapat berisi semua logika validasi menggunakan antarmuka IValidatableObject. ViewModel berinteraksi dengan DB pada lapisan model yang dapat menggunakan model yang diketik kuat. MVVM di WPF ADALAH pengontrol MVC. Tetapi pengontrol MVC jauh lebih bersih, itu penting penangan perutean.
John Peters

9

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.


1
IMHO saya berpendapat bahwa "membuat pengontrol lebih dapat digunakan kembali" adalah pernyataan yang terlalu luas dan kontra-produktif untuk "pengontrol" ASP.Net umum (yaitu bukan lapisan logika bisnis) karena pengontrol tersebut biasanya berisi bagian-bagian dari aplikasi yang merupakan aplikasi- spesifik . Ini adalah Views, Model, ViewModels dan logika bisnis yang perlu digunakan kembali. Saya akan berpikir memperlakukan modul logika bisnis sebagai penyedia layanan, bukan sebagai pengendali, akan menjadi pilihan yang lebih baik.
Hilang Coding

Tetapi Anda berbicara tentang "ViewModel" di Asp.net, bukan tentang pola desain MVVM. Dua hal berbeda.
Luis

9

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.


Wow ... jadi MVC dan MVVM berasal dari SmallTalk ?? Mereka jauh di depan dari waktu mereka ...
MattE

Sebenarnya, mengatakan itu berasal dari Model Presentasi Martin Fowler tidak akurat. Sangat sulit untuk menentukan yang mana yang datang terlebih dahulu, tetapi kedua pola (memungkinkan bahwa mereka benar-benar pola yang sama) diterima secara mandiri dan kira-kira bersamaan.
wekempf

6

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.


Apa istilah 'pengembangan web' 'MVC' tidak lebih dari pemisahan keprihatinan dan bukan MVC otentik yang mendahului web.
Terrence Brannon

4

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


4

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.


4

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.

1
Penjelasan terbaik
p32094

2

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.


2

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.


2

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.


2

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.


1

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.


1

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. masukkan deskripsi gambar di sini

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. masukkan deskripsi gambar di sini

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.