Pertanyaan Apa MVP dan MVC dan apa bedanya?


Ketika mencari di luar RAD (drag-drop dan mengkonfigurasi) cara membangun antarmuka pengguna yang banyak alat mendorong Anda cenderung menemukan tiga pola desain yang disebut Model-View-Controller, Model-Tampilan-Presenter dan Model-View-ViewModel. Pertanyaan saya ada tiga bagian darinya:

  1. Isu apa yang dikemukakan pola-pola ini?
  2. Bagaimana mereka mirip?
  3. Bagaimana mereka berbeda?

1834
2017-08-05 10:06


asal


Jawaban:


Model-Tampilan-Presenter

Di MVP, Presenter berisi logika bisnis UI untuk View. Semua panggilan dari delegasi View langsung ke Presenter. Presenter juga dipisahkan langsung dari View dan berbicara melalui antarmuka. Ini untuk memungkinkan mengejek View dalam tes unit. Satu atribut umum MVP adalah harus ada banyak pengiriman dua arah. Misalnya, ketika seseorang mengklik tombol "Simpan", pengendali event mendelegasikan ke metode "OnSave" Presenter. Setelah penyimpanan selesai, Presenter kemudian akan memanggil kembali View melalui antarmukanya sehingga View dapat menampilkan bahwa penyimpanan telah selesai.

MVP cenderung menjadi pola yang sangat alami untuk mencapai presentasi terpisah di Formulir Web. Alasannya adalah bahwa View selalu dibuat pertama kali oleh runtime ASP.NET. Kamu bisa cari tahu lebih lanjut tentang kedua varian.

Dua variasi utama

Tampilan Pasif: Tampilannya sebisa mungkin dan mengandung hampir nol logika. Presenter adalah orang tengah yang berbicara tentang Pandangan dan Model. Tampilan dan Model sepenuhnya terlindung dari satu sama lain. Model dapat meningkatkan acara, tetapi Presenter berlangganan untuk memperbarui Tampilan. Dalam Pasif Tampilan tidak ada pengikatan data langsung, sebagai gantinya View menampilkan properti setter yang digunakan oleh Presenter untuk mengatur data. Semua negara dikelola di Presenter dan bukan Tampilan.

  • Pro: permukaan testability maksimum; pemisahan bersih dari Lihat dan Model
  • Con: lebih banyak pekerjaan (misalnya semua properti setter) karena Anda melakukan semua data yang mengikat diri sendiri.

Pengawas Pengawas: Presenter menangani gerakan pengguna. The View berikatan langsung dengan Model melalui pengikatan data. Dalam hal ini adalah tugas Presenter untuk mewariskan Model ke Tampilan sehingga dapat mengikatnya. Presenter juga akan berisi logika untuk gerakan seperti menekan tombol, navigasi, dll.

  • Pro: dengan memanfaatkan penyatuan data jumlah kode dikurangi.
  • Con: ada permukaan yang kurang dapat diuji (karena pengikatan data), dan ada lebih sedikit enkapsulasi dalam Tampilan karena berbicara langsung ke Model.

Model-View-Controller

Dalam MVC, Pengendali bertanggung jawab untuk menentukan Tampilan mana yang akan ditampilkan sebagai respons terhadap tindakan apa pun termasuk ketika aplikasi dimuat. Ini berbeda dari MVP di mana tindakan rute melalui View ke Presenter. Dalam MVC, setiap tindakan dalam View berkorelasi dengan panggilan ke Pengontrol bersama dengan tindakan. Di web setiap tindakan melibatkan panggilan ke URL di sisi lain yang ada Pengontrol yang merespons. Setelah Pengontrol menyelesaikan pemrosesan, ini akan mengembalikan Tampilan yang benar. Urutan berlanjut dengan cara itu sepanjang kehidupan aplikasi:

Aksi dalam Tampilan
        -> Panggil ke Kontroler
        -> Logika Kontrol
        -> Pengontrol mengembalikan View.

Satu perbedaan besar lainnya tentang MVC adalah bahwa View tidak secara langsung mengikat ke Model. Tampilan hanya membuat, dan benar-benar tanpa negara. Dalam implementasi MVC, View biasanya tidak memiliki logika apa pun dalam kode di belakang. Ini bertentangan dengan MVP yang mutlak diperlukan karena, jika View tidak didelegasikan kepada Presenter, itu tidak akan pernah dipanggil.

Model Presentasi

Satu pola lain untuk dilihat adalah Model Presentasi pola. Dalam pola ini tidak ada Presenter. Sebagai gantinya, Tampilan akan mengikat langsung ke Model Presentasi. Model Presentasi adalah Model yang dibuat khusus untuk View. Ini berarti Model ini dapat mengekspos properti yang tidak akan pernah diletakkan pada model domain karena akan menjadi pelanggaran pemisahan-of-concern. Dalam hal ini, Model Presentasi mengikat ke model domain, dan dapat berlangganan acara yang berasal dari Model itu. The View kemudian berlangganan acara yang berasal dari Model Presentasi dan memperbarui sendiri yang sesuai. Model Presentasi dapat mengekspos perintah yang digunakan oleh tampilan untuk memohon tindakan. Keuntungan dari pendekatan ini adalah bahwa Anda pada dasarnya dapat menghapus kode-belakang sama sekali sebagai PM sepenuhnya merangkum semua perilaku untuk tampilan. Pola ini adalah kandidat yang sangat kuat untuk digunakan dalam aplikasi WPF dan juga disebut Model-View-ViewModel.

Ada sebuah Artikel MSDN tentang Model Presentasi dan satu bagian dalam Panduan Aplikasi Komposit untuk WPF (mantan Prisma) tentang Pola Presentasi Terpisah


1796
2017-08-05 10:21



Saya menulis blog tentang ini beberapa waktu lalu, mengutip Posting Todd Snyder yang luar biasa tentang perbedaan antara keduanya:

Berikut adalah perbedaan utama antara   pola:

Pola MVP

  • Tampilan lebih longgar digabungkan ke model. Presenter adalah   bertanggung jawab untuk mengikat model   pandangan.
  • Lebih mudah ke tes unit karena interaksi dengan tampilan sudah selesai   sebuah antarmuka
  • Biasanya melihat ke presenter peta satu ke satu. Pandangan kompleks mungkin ada   presenter multi.

Pola MVC

  • Kontroler didasarkan pada perilaku dan dapat dibagi di seluruh   dilihat
  • Dapat bertanggung jawab untuk menentukan tampilan mana yang akan ditampilkan

Ini adalah penjelasan terbaik di web yang bisa saya temukan.


384
2017-07-06 22:18



Ini adalah penyederhanaan yang berlebihan dari banyak varian dari pola desain ini, tetapi ini adalah bagaimana saya suka berpikir tentang perbedaan di antara keduanya.

MVC

MVC

MVP

enter image description here


367
2017-09-12 20:47



Berikut adalah ilustrasi yang merepresentasikan alur komunikasi

enter image description here 

enter image description here


208
2017-08-25 21:22



MVP adalah tidak tentu saja skenario di mana View bertanggung jawab (lihat Taligent's MVP misalnya).
Saya merasa sangat disayangkan bahwa orang-orang masih mengkhotbahkan ini sebagai sebuah pola (pandangan yang bertanggung jawab) yang bertentangan dengan anti-pola karena bertentangan dengan "Ini hanya sebuah pandangan" (Pragmatic Programmer). "Ini hanya pandangan" menyatakan bahwa pandangan terakhir yang ditunjukkan kepada pengguna adalah kekhawatiran sekunder dari aplikasi. Pola MVP Microsoft membuat penggunaan kembali Tampilan jauh lebih sulit dan nyaman alasan perancang Microsoft dari mendorong praktik buruk.

Terus terang, saya pikir kekhawatiran mendasar dari MVC berlaku untuk setiap implementasi MVP dan perbedaannya hampir sepenuhnya semantik. Selama Anda mengikuti pemisahan kekhawatiran antara tampilan (yang menampilkan data), pengontrol (yang menginisialisasi dan mengontrol interaksi pengguna) dan model (data dan / atau layanan yang mendasar)) maka Anda akan merasakan manfaat dari MVC . Jika Anda merasakan manfaatnya maka siapa yang benar-benar peduli apakah pola Anda adalah MVC, MVP atau Pengawas Pengawas? Satu-satunya nyata Pola tetap sebagai MVC, sisanya hanya berbeda rasa itu.

Mempertimbangkan ini artikel yang sangat menarik yang secara komprehensif mencantumkan sejumlah penerapan yang berbeda ini. Anda dapat mencatat bahwa pada dasarnya mereka melakukan hal yang sama tetapi sedikit berbeda.

Saya pribadi berpikir MVP baru-baru ini diperkenalkan kembali sebagai istilah yang mudah diingat untuk mengurangi argumen antara para fanatik semantik yang berdebat apakah sesuatu itu benar-benar MVC atau tidak atau untuk membenarkan Microsoft Rapid Application Development tools. Tak satu pun dari alasan-alasan ini dalam buku saya membenarkan keberadaannya sebagai pola desain yang terpisah.


148
2017-08-06 22:51



MVP: tampilan bertanggung jawab.

Pandangan, dalam banyak kasus, menciptakan presenternya. Presenter akan berinteraksi dengan model dan memanipulasi tampilan melalui antarmuka. Tampilan terkadang akan berinteraksi dengan presenter, biasanya melalui beberapa antarmuka. Ini turun ke implementasi; apakah Anda ingin pandangan memanggil metode pada presenter atau apakah Anda ingin tampilan untuk memiliki acara presenter mendengarkan? Itu bermuara pada ini: Pandangan tahu tentang presenter. Tampilan didelegasikan kepada presenter.

MVC: controller bertanggung jawab.

Pengontrol dibuat atau diakses berdasarkan beberapa acara / permintaan. Kontroler kemudian membuat tampilan yang sesuai dan berinteraksi dengan model untuk lebih mengonfigurasi tampilan. Itu bermuara pada: pengendali menciptakan dan mengelola pandangan; pandangannya adalah slave ke controller. Pandangan tidak tahu tentang pengontrol.


90
2017-12-20 02:10



enter image description here

MVC (Model View Controller)

Masukan diarahkan pada Pengontrol terlebih dahulu, bukan tampilan. Masukan itu mungkin berasal dari pengguna yang berinteraksi dengan laman, tetapi bisa juga dari sekadar memasukkan url spesifik ke browser. Dalam kedua kasus, ini adalah Kontroler yang dihubungkan dengan untuk memulai beberapa fungsi. Ada hubungan banyak-ke-satu antara Controller dan View. Itu karena satu pengontrol dapat memilih tampilan berbeda untuk ditampilkan berdasarkan operasi yang sedang dijalankan. Perhatikan panah satu arah dari Controller to View. Ini karena View tidak memiliki pengetahuan atau referensi ke pengontrol. Pengontrol tidak mengembalikan Model, jadi ada pengetahuan antara View dan Model yang diharapkan dilewatkan ke dalamnya, tetapi bukan Controller yang melayaninya.

MVP (Model View Presenter)

Masukan dimulai dengan Tampilan, bukan Presenter. Ada pemetaan satu-ke-satu antara View dan Presenter terkait. The View memegang referensi ke Presenter. Presenter juga bereaksi terhadap peristiwa yang dipicu dari View, sehingga ia sadar akan Tampilan yang terkait dengannya. Presenter memperbarui Tampilan berdasarkan tindakan yang diminta yang dilakukannya pada Model, tetapi Tampilan tidak sadar Model.

Untuk lebih Referensi


62
2017-08-05 10:22



  • MVP = Model-Tampilan-Presenter
  • MVC = Model-View-Controller

    1. Kedua pola presentasi. Mereka memisahkan dependensi antara Model (pikirkan objek Domain), layar / halaman web Anda (Tampilan), dan bagaimana seharusnya UI Anda berperilaku (Presenter / Pengatur)
    2. Mereka cukup mirip dalam konsep, orang-orang menginisialisasi Presenter / Controller berbeda tergantung pada selera.
    3. Artikel bagus tentang perbedaannya adalah sini. Paling penting adalah bahwa pola MVC memiliki Model memperbarui View.

31
2017-08-08 05:55



Juga perlu diingat adalah bahwa ada berbagai jenis MVP juga. Fowler telah memecah pola menjadi dua - View Pasif dan Kontroler Pengawas.

Saat menggunakan Pasif View, Tampilan Anda biasanya menerapkan antarmuka halus dengan pemetaan properti lebih atau kurang langsung ke widget UI yang mendasari. Misalnya, Anda mungkin memiliki ICustomerView dengan properti seperti Nama dan Alamat.

Implementasi Anda mungkin terlihat seperti ini:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Kelas Presenter Anda akan berbicara dengan model dan "memetakan" ke tampilan. Pendekatan ini disebut "Pasif View". Manfaatnya adalah tampilan ini mudah diuji, dan lebih mudah untuk berpindah antar platform UI (Web, Windows / XAML, dll.). Kerugiannya adalah bahwa Anda tidak dapat memanfaatkan hal-hal seperti penyatuan data (yang sangat kuat dalam kerangka seperti WPF dan Silverlight).

Rasa kedua dari MVP adalah Pengawas Pengawas. Dalam hal ini, Tampilan Anda mungkin memiliki properti yang disebut Pelanggan, yang sekali lagi merupakan basis data ke widget UI. Anda tidak perlu memikirkan sinkronisasi dan mikro-mengelola tampilan, dan Pengawas Pengawas dapat masuk dan membantu ketika dibutuhkan, misalnya dengan logika interaksi yang dikompilasi.

"Rasa" ketiga dari MVP (atau seseorang mungkin akan menyebutnya pola terpisah) adalah Model Presentasi (atau kadang-kadang disebut Model-View-ViewModel). Dibandingkan dengan MVP, Anda "menggabungkan" M dan P ke dalam satu kelas. Anda memiliki objek pelanggan yang widget UI Anda terikat dengan data, tetapi Anda juga memiliki bidang tambahan UI-spesifik seperti "IsButtonEnabled", atau "IsReadOnly", dll.

Saya pikir sumber daya terbaik yang saya temukan untuk arsitektur UI adalah serangkaian posting blog yang dilakukan oleh Jeremy Miller di The Build Your Own CAB Series Daftar Isi. Dia menutupi semua rasa MVP dan menunjukkan kode C # untuk menerapkannya.

Saya juga telah membuat blog tentang pola Model-View-ViewModel dalam konteks Silverlight di YouCard Kembali dikunjungi: Menerapkan pola ViewModel.


31
2018-04-06 13:51



Ada banyak jawaban untuk pertanyaan itu, tetapi saya merasa ada kebutuhan untuk beberapa jawaban yang sangat sederhana yang dengan jelas membandingkan keduanya. Berikut diskusi yang saya buat ketika seorang pengguna mencari nama film dalam aplikasi MVP dan MVC:

Pengguna: Klik klik ...

Melihat: Siapa itu? [MVP|MVC]

Pengguna: Saya baru saja mengklik tombol pencarian ...

Melihat: Ok, tunggu sebentar…. [MVP|MVC]

( Melihat memanggil Pembawa acara|Kontroler ...) [MVP|MVC]

Melihat: Hey Pembawa acara|Kontroler, Pengguna baru saja mengklik tombol pencarian, apa yang harus saya lakukan? [MVP|MVC]

Pembawa acara|Kontroler: Hey Melihat, apakah ada istilah pencarian di halaman itu? [MVP|MVC]

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

Pembawa acara: Terima kasih Melihat, ... sementara itu saya mencari istilah pencarian di Model, tunjukkan padanya bilah kemajuan [MVP|MVC]

( Pembawa acara|Kontroler yang memanggil Model ...) [MVP|MVC]

Pembawa acara|Kontroler: Hey Model, Apakah Anda memiliki kecocokan untuk istilah pencarian ini ?: "piano" [MVP|MVC]

Model: Hey Pembawa acara|Kontroler, biarkan aku memeriksa ... [MVP|MVC]

( Model sedang membuat permintaan ke database film ...) [MVP|MVC]

( Setelah beberapa saat ... )

-------------- Di sinilah MVP dan MVC mulai menyimpang ---------------

Model: Saya menemukan daftar untuk Anda, Pembawa acara, ini dia di JSON “[{" name ":" Piano Teacher "," tahun ": 2001}, {" nama ":" Piano "," tahun ": 1993}]” [MVP]

Model: Ada beberapa hasil yang tersedia, Kontroler. Saya telah membuat variabel lapangan dalam instance saya dan mengisinya dengan hasilnya. Namanya adalah "searchResultsList" [MVC]

(Pembawa acara|Kontroler Terima kasih Model dan kembali ke Melihat) [MVP|MVC]

Pembawa acara: Terima kasih telah menunggu Melihat, Saya menemukan daftar hasil yang cocok untuk Anda dan mengaturnya dalam format yang layak: ["Piano Teacher 2001", "Piano 1993"]. Tolong tunjukkan kepada pengguna dalam daftar vertikal. Juga tolong sembunyikan bilah kemajuan sekarang [MVP]

Kontroler: Terima kasih telah menunggu Melihat, Saya sudah bertanya Model tentang permintaan pencarian Anda. Ia mengatakan telah menemukan daftar hasil yang cocok dan menyimpannya dalam variabel bernama "searchResultsList" di dalam instance. Anda bisa mendapatkannya dari sana. Juga tolong sembunyikan bilah kemajuan sekarang [MVC]

Melihat: Terima kasih banyak Pembawa acara [MVP]

Melihat: Terima kasih "Controller" [MVC] (Sekarang Melihat mempertanyakan dirinya: Bagaimana seharusnya saya menyajikan hasil yang saya dapatkan dari Model kepada pengguna? Haruskah tahun produksi film datang pertama atau terakhir ...? Haruskah itu dalam daftar vertikal atau horizontal? ...)

Jika Anda tertarik, saya telah menulis serangkaian artikel yang membahas pola arsitektur aplikasi (MVC, MVP, MVVP, arsitektur bersih, ...) ditemani oleh Github repo sini. Meskipun contohnya ditulis untuk android, prinsip-prinsip yang mendasarinya dapat diterapkan pada media apa pun.


17
2017-08-05 10:20