Pertanyaan Manfaat MVVM atas MVC


Akhirnya mulai melakukan pengembangan Silverlight dan saya menemukan MVVM. Saya kenal dengan MVC dan artikel yang saya baca mengatakan karena XAML, MVC tidak akan berhasil. Tidak memiliki terlalu banyak pengalaman dalam XAML jelas adalah alasan saya tidak mendapatkan poin ini.

Dapatkah seseorang menjelaskan mengapa MVC tidak cocok dan mengapa MVVM lebih baik untuk pengembangan Silverlight?

Terima kasih JD


41
2017-10-20 11:32


asal


Jawaban:


Perbedaannya sangat tipis, yang dapat saya jelaskan terbaik dengan membandingkan MVC di ASP.NET dan MVVM di WPF.

Di ASP.NET MVC, permintaan datang dari server web dan ditangani langsung oleh Pengontrol. Pengontrol menentukan Tampilan yang sesuai dan mengisinya dengan Model. Controller kemudian melepaskan instance ini ke sistem yang mendasari yang memberikan hasil kepada klien. Anda dapat melihat bahwa Pengontrol adalah yang pertama dan terakhir yang bertindak.

Dalam MVVM, UI (Tampilan), menghadap pengguna dan mengambil input pengguna secara langsung. Dalam View, Perintah dalam ViewModel (yang merupakan DataContext dari View) dipicu oleh aktivitas ini. Kontrol mengalir ke ViewModel yang menginterpretasikan apa yang telah dikirim oleh View dan menyiapkan Modelnya. Setelah kontrol mengalir kembali ke Tampilan, pembaruan itu sendiri sesuai dengan perubahan dalam Model. Jika View baru diperlukan, ViewModel mengkomunikasikan ini dengan NavigationService (atau metode apa pun dari navigasi yang digunakan aplikasi Anda), yang merupakan lingkup dari Window atau Frame - komponen UI. Anda dapat melihat bahwa ViewModel bukan yang pertama dan terakhir untuk bertindak; Tampilan memainkan peran yang jauh lebih besar daripada di MVC.

Arsitektur WPF / Silverlight adalah alasan mengapa hal-hal dilakukan dengan cara ini. Perintah, mengikat dan infrastruktur navigasi tidak dapat dikontrol / diganti oleh Pengontrol; mereka terintegrasi dengan UI. Jadi Pengendali harus duduk di bawah View dan mengambil peran yang lebih pasif.


57
2017-10-20 12:05



MVVM dirancang terutama karena XAML dan untuk membuat data yang lebih sederhana, sangat mirip dengan MVP. Manfaat utama adalah cara yang lebih sederhana untuk memanipulasi antarmuka pengguna (ViewModel atau Presenter menangani tugas tersebut daripada Model yang harus mem-burn event ke View setelah dimanipulasi oleh Controller).

Dua artikel terbaik yang pernah saya temui yang membantu saya memahami prinsipnya MVC vs MVP vs MVVM dan MVVM untuk Folks Tarded Like Me atau MVVM dan Apa artinya bagiKu


13
2017-10-21 08:55



Komponen Pemisah

Di MVC, Anda memiliki hubungan segitiga antara komponen. Yaitu: Controller memiliki View dan Model. The View bergantung pada definisi Model. Model harus memenuhi persyaratan Tampilan. Pikirkan arsitektur Hub (controller) dan spoke (lihat dan model)

Dalam MVVM, pikirkan bahwa segitiga tersebut menjadi datar dengan setiap komponen hanya mengetahui satu sama lain dalam rantai. Yaitu: View-> ViewModel-> Model

Model tidak mengetahui apa pun di atas tumpukan. ViewModel hanya mengetahui Model Tampilan hanya mengetahui Model Tampilan - tidak mengetahui Model.

Mengapa ini penting? 

Ini adalah inti dari pertanyaan aslinya.

Tujuan utamanya adalah lebih jauh abstraksi arsitektur Anda. Ini biasanya akan mengarah ke kode yang lebih sedikit, tetapi lebih sedikit titik kontak antar objek. Lebih sedikit titik kontak penting karena ini mengarah ke kode yang lebih lincah. Semakin banyak kopling / kontak Kelas A dengan Kelas B, semakin besar dampak perubahan Kelas A. Mengurangi dampak perubahan adalah salah satu manfaat utama dari arsitektur yang baik.

Untuk sepenuhnya memahami hal ini, ada gunanya untuk merenungkan tentang apa yang benar-benar diwakili oleh komponen. Apa itu View, Controller, ViewModel, atau Model? Apakah mereka definisi literal, atau lebih dari konsep abstrak?

Dalam pengalaman saya, lebih bermanfaat untuk mempertimbangkan Model menjadi sekelompok kelas / benda yang berhubungan dengan konstruksi dan ketekunan data. Ini bukan hanya objek biasa dengan properti. Ini adalah kelas yang melakukan pengambilan data, menyimpan data, sebuah pabrik yang membangun objek-objek biasa. Ini adalah lapisan fasad yang menyediakan API yang jelas ke dalam data. Haruskah lapisan fasad ini dirujuk langsung dari View?

Menurut saya, seharusnya tidak. Di MVC, jawaban itu juga "tidak". Pengontrol mengambil data dari Model. Dalam hal itu, MVC dan MVVM mencapai tujuan yang sama. Di mana dua arsitektur berbeda adalah bagaimana data dan tampilan dihubungkan.

Seperti Model, Tampilan dapat menjadi kumpulan kelas yang berkoordinasi satu sama lain, membuat tampilan presentasi. Ini bisa terdiri dari View Controller + View dalam kasus platform seluler (Lihat Pengontrol di iOS, Aktivitas di Android). Dalam banyak kasus, Anda perlu kelas untuk memuat dokumen tampilan ke dalam memori dan memperbarui properti tampilan. Ada banyak pekerjaan yang harus dilakukan di sini. Dalam MVC, Controller dengan cepat menjadi kelas 'kitchen sink' - semacam tempat pembuangan untuk segala sesuatu yang berhubungan dengan konteks pengguna saat ini.

Ketika Anda mengalikan ini lebih dari lusinan pandangan potensial dalam aplikasi Anda, Anda berakhir dengan banyak ketergantungan yang mendalam antara kode Model back-end Anda dan kode tampilan front-end Anda. Dengan kelas Controller yang besar, dependensi ini tidak langsung terlihat.

Meratakan ketergantungan Anda

MVVM mendatarkan dependensi. Ini menciptakan fokus. Apa itu fokus? Kemampuan untuk bekerja pada satu bagian dari fungsi tanpa gangguan dari semua dependensi lainnya. Sekarang Anda dapat mulai menulis tes unit pada kode yang sebelumnya dianggap tidak dapat dipertahankan.

Model Tampilan bertindak sebagai fasad antara Tampilan dan Model. Model Tampilan memenuhi kebutuhan Tampilan - secara teknis, Tampilan harus memiliki Model Tampilan. Jika View memerlukan data dari berbagai sumber, Model Tampilan merangkum komposisi sumber data terpisah menjadi objek tunggal, terpadu, dan tidak dinormalkan. Jika tampilan perlu memanggil kembali Model atau tujuan lain, Model Tampilan menyediakan kait dan rute panggilan yang sesuai.

Pertimbangkan cara kerja panel tambalan jaringan. Pada pandangan pertama, ini tampak berlebihan - mengapa tidak hanya kabel ethernet Anda dari titik A ke titik B. Tetapi dengan pengalaman, Anda akan memahami bahwa panel patch memberi Anda bagian kunci abstraksi yang memungkinkan Anda untuk mengubah rute Titik B tanpa mempengaruhi Point A. Ini yang dilakukan oleh Model Tampilan Anda.

Sekarang setelah Anda memiliki abstraksi yang bersih antara View dan Model Anda, konsekuensinya adalah View / Controller Anda hanya memperhatikan presentasi. Ini berarti tidak seharusnya berurusan dengan pelokalan atau pemformatan - ia mendapatkan data dan menyajikan data. Model Tampilan Anda adalah tempat yang ideal untuk menempatkan pemajangan data pra-tampilan semacam ini. Katakanlah Anda perlu memfilter data berdasarkan kriteria. Sekali lagi, Model Tampilan adalah knowledgable tentang data Model (View Anda tidak) dan merupakan tempat yang bagus untuk menempatkan kode semacam ini.

Setelah Anda mulai mengatur persyaratan aplikasi Anda dengan cara ini, kode View / Controller Anda menjadi lebih bersih, dan ketika sesuatu perlu diubah, implikasinya menjadi lebih jelas, yang menyebabkan lebih sedikit bug.

Testability

Satu catatan akhir tentang testability: Dengan meratakan dependensi, itu mempermudah penyuntikkan dependensi tiruan ke dalam tes Anda. Itu membuat pengujian lebih mudah dan lebih ringkas. Model Tampilan Anda menjadi sesuatu yang dapat Anda definisikan dengan jelas pada kasus uji coba.


8
2017-12-17 19:15



Saya pikir idenya adalah MVVM itu lebih baik cocok untuk XAML daripada MVC. Mengatakan MVC 'tidak cocok' sedikit berlebihan.

Dan mengapa MVVM lebih baik? Terutama karena pengikatan data yang luar biasa dan pengikatan perintah dalam XAML. Lihat artikel ini.


4
2017-10-20 12:09



Saya pikir manfaat lainnya adalah kurva belajar. Karena sebagian besar pengembang dalam teknologi frontend telah menggunakan jenis pengkodean MVVM, lebih mudah bagi mereka untuk mengadopsi yang sama daripada menggunakan model pengontrol di mana mereka harus menyampaikan setiap permintaan dari tampilan ke pengendali dan membuatnya berkomunikasi dengan Model.


4
2017-11-14 02:19