Apa itu MVP dan MVC dan apa bedanya?


2133

Saat melihat di luar cara RAD (drag-drop dan configure) cara membangun antarmuka pengguna yang banyak alat dorong Anda cenderung menemukan tiga pola desain yang disebut Model-View-Controller , Model-View-Presenter dan Model-View-ViewModel . Pertanyaan saya ada tiga bagian:

  1. Masalah apa yang ditangani oleh pola-pola ini?
  2. Bagaimana mereka serupa?
  3. Bagaimana mereka berbeda?


2
IDK, tetapi seharusnya untuk MVC asli, itu dimaksudkan untuk digunakan dalam yang kecil. Setiap tombol, label, dll, memiliki pandangan dan objek pengontrolnya sendiri, atau setidaknya itulah yang diklaim Paman Bob. Saya pikir dia berbicara tentang Smalltalk. Lihat ceramahnya di YouTube, mereka menarik.
still_dreaming_1

MVP menambahkan lapisan tipuan tambahan dengan memisahkan View-Controller menjadi View dan Presenter ...
the_prole

2
Perbedaan utama adalah bahwa dalam MVC Controller tidak meneruskan data apa pun dari Model ke View. Itu hanya memberitahukan View untuk mendapatkan data dari Model itu sendiri. Namun, di MVP, tidak ada koneksi antara View dan Model. Presenter sendiri mendapatkan data apa saja yang diperlukan dari Model dan meneruskannya ke View untuk ditampilkan. Lebih lanjut tentang ini bersama-sama dengan sampel Android di semua pola arsitektur ada di sini: digigene.com/category/android/android-architecture
Ali Nem

Mereka disebut pola arsitektur bukan pola desain . Jika Anda ingin mengetahui perbedaannya, periksa ini
Hasan El-Hefnawy

Jawaban:


1997

Model-View-Presenter

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

MVP cenderung menjadi pola yang sangat alami untuk mencapai presentasi terpisah dalam Formulir Web. Alasannya adalah bahwa tampilan selalu dibuat pertama kali oleh runtime ASP.NET. Anda dapat mengetahui lebih lanjut tentang kedua varian .

Dua variasi utama

Tampilan Pasif: Tampilan sebodoh mungkin dan berisi hampir nol logika. Presenter adalah orang tengah yang berbicara dengan View and the Model. Tampilan dan Model sepenuhnya terlindung dari satu sama lain. Model dapat memunculkan acara, tetapi Presenter berlangganan untuk memperbaharui View. Dalam Tampilan Pasif tidak ada pengikatan data langsung, sebagai gantinya Tampilan memperlihatkan properti setter yang digunakan Presenter untuk mengatur data. Semua status dikelola dalam Presenter dan bukan View.

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

Supervising Controller: Presenter menangani gerakan pengguna. Tampilan mengikat Model secara langsung melalui pengikatan data. Dalam hal ini adalah tugas Presenter untuk menyerahkan 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 berkurang.
  • Con: ada permukaan yang kurang dapat diuji (karena pengikatan data), dan ada lebih sedikit enkapsulasi dalam View karena berbicara langsung ke Model.

Model-View-Controller

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

    Aksi di Tampilan
        -> Panggilan ke Kontroler
        -> Logika Pengendali
        -> Controller mengembalikan View.

Satu perbedaan besar lainnya tentang MVC adalah bahwa View tidak secara langsung mengikat ke Model. Tampilannya sederhana, dan sepenuhnya stateless. Dalam implementasi MVC, View biasanya tidak memiliki logika dalam kode di belakang. Ini bertentangan dengan MVP di mana itu mutlak diperlukan karena, jika View tidak mendelegasikan ke Presenter, itu tidak akan pernah dipanggil.

Model Presentasi

Satu pola lain untuk dilihat adalah Model Presentasipola. Dalam pola ini tidak ada Presenter. Alih-alih, Tampilan mengikat langsung ke Model Presentasi. Model Presentasi adalah Model yang dibuat khusus untuk Tampilan. Ini berarti Model ini dapat mengekspos properti yang tidak akan pernah ditempatkan pada model domain karena itu akan menjadi pelanggaran pemisahan-masalah. Dalam hal ini, Model Presentasi mengikat ke model domain, dan dapat berlangganan acara yang berasal dari Model itu. View kemudian berlangganan ke acara yang berasal dari Model Presentasi dan memperbarui sendiri sesuai. Model Presentasi dapat mengekspos perintah yang digunakan tampilan untuk menjalankan tindakan. Keuntungan dari pendekatan ini adalah Anda pada dasarnya dapat menghapus kode-belakang sama sekali karena PM sepenuhnya merangkum semua perilaku untuk tampilan.Model-View-ViewModel .

Ada artikel MSDN tentang Model Presentasi dan bagian dalam Panduan Aplikasi Komposit untuk WPF (sebelumnya Prisma) tentang Pola Presentasi Terpisah


27
Bisakah Anda memperjelas frasa ini? Ini berbeda dari MVP di mana tindakan merutekan melalui View ke Presenter. Di MVC, setiap tindakan di Tampilan berkorelasi dengan panggilan ke Pengontrol bersama dengan tindakan. Bagi saya, itu terdengar seperti hal yang sama, tetapi saya yakin Anda menggambarkan sesuatu yang berbeda.
Panzercrisis

16
@ Panzercrisis Saya tidak yakin apakah ini yang dimaksud penulis, tapi ini yang saya pikir ingin mereka katakan. Seperti jawaban ini - stackoverflow.com/a/2068/74556 menyebutkan, dalam MVC, metode pengontrol didasarkan pada perilaku - dengan kata lain, Anda dapat memetakan banyak tampilan (tetapi perilaku yang sama) ke satu pengontrol. Dalam MVP, presenter digabungkan lebih dekat ke tampilan, dan biasanya menghasilkan pemetaan yang lebih dekat dengan satu-ke-satu, yaitu aksi peta tindakan dengan metode presenter yang sesuai. Anda biasanya tidak akan memetakan tindakan tampilan lain ke metode presenter lain (dari tampilan lain).
Dustin Kendall

2
Catatan yang MVC sering digunakan oleh kerangka kerja web seperti Laravel, di mana permintaan URL yang diterima (mungkin dibuat oleh pengguna) ditangani oleh Controllerdan HTML yang dihasilkan oleh Viewdikirim ke klien - Jadi, Viewini adalah bagian dari backend dan pengguna tidak pernah dapat mengaksesnya secara langsung, dan jika Anda mengalami hal sebaliknya, anggap itu sebagai ekstensi-MVC (atau bahkan pelanggaran). @ Panzercrisis, Ini berbeda dari MVP(seperti yang digunakan di AndroidOS) di mana actions route through the View to the Presenterdan pengguna memiliki akses langsung ke View.
Top-Master

455

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

MVC

MVC

MVP

masukkan deskripsi gambar di sini


10
Ini adalah penggambaran skematis yang bagus, menunjukkan abstraksi dan isolasi lengkap dari segala GUI terkait (lihat hal-hal) dari API presenter. Satu poin minor: Presenter master dapat digunakan di mana hanya ada satu presenter, bukan satu view, tetapi diagram Anda adalah yang terbersih. IMO, perbedaan terbesar antara MVC / MVP adalah bahwa MVP mencoba untuk menjaga pandangan benar-benar kosong dari apa pun selain tampilan 'kondisi tampilan' saat ini (data tampilan), sementara juga melarang pandangan pengetahuan tentang objek Model. Jadi antarmuka, perlu ada di sana, untuk menyuntikkan keadaan itu.

4
Gambar yang bagus. Saya menggunakan MVP cukup banyak, jadi saya ingin membuat satu poin. Dalam pengalaman saya, Presenter perlu berbicara satu sama lain cukup sering. Hal yang sama berlaku untuk Model (atau objek Bisnis). Karena "garis biru" tambahan komunikasi yang ada di gambar MVP Anda, hubungan Presenter-Model dapat menjadi sangat terjerat. Oleh karena itu, saya cenderung untuk menjaga hubungan Presenter-Model satu-ke-satu vs satu-ke-banyak. Ya, itu memerlukan beberapa metode delegasi tambahan pada Model, tetapi mengurangi banyak sakit kepala jika API Model berubah atau perlu refactoring.
splungebob

3
Contoh MVC salah; ada hubungan ketat 1: 1 antara tampilan dan pengontrol. Menurut definisi, pengontrol menafsirkan input gerakan manusia untuk menghasilkan peristiwa untuk model dan melihat sama untuk kontrol tunggal. Lebih sederhana, MVC dimaksudkan untuk digunakan dengan masing-masing widget. Satu widget, satu tampilan, satu kontrol.
Samuel A. Falvo II

3
@ SamuelA.FalvoII tidak selalu, ada 1: Banyak antara pengontrol dan tampilan di ASP.NET MVC: stackoverflow.com/questions/1673301/…
StuperUser

4
@StuperUser - Tidak yakin apa yang saya pikirkan ketika saya menulis itu. Anda benar, tentu saja, dan mengingat kembali apa yang saya tulis, saya harus bertanya-tanya apakah saya memiliki konteks lain dalam pikiran yang gagal saya artikulasikan. Terima kasih atas koreksinya.
Samuel A. Falvo II

421

Saya blog tentang hal ini beberapa waktu lalu, mengutip postingan bagus Todd Snyder tentang perbedaan antara keduanya :

Berikut adalah perbedaan utama antara pola:

Pola MVP

  • Tampilan lebih longgar digabungkan ke model. Presenter bertanggung jawab untuk mengikat model ke tampilan.
  • Lebih mudah untuk unit test karena interaksi dengan tampilan adalah melalui antarmuka
  • Biasanya melihat ke presenter peta satu ke satu. Tampilan kompleks mungkin memiliki banyak penyaji.

Pola MVC

  • Pengontrol didasarkan pada perilaku dan dapat dibagi lintas pandangan
  • Dapat bertanggung jawab untuk menentukan tampilan mana yang akan ditampilkan

Ini adalah penjelasan terbaik di web yang bisa saya temukan.


15
Saya tidak mengerti bagaimana dalam tampilan dapat digabungkan kurang lebih dekat dengan model ketika dalam kedua kasus seluruh titik adalah untuk sepenuhnya memisahkan mereka. Saya tidak menyiratkan Anda mengatakan sesuatu yang salah - hanya bingung tentang apa yang Anda maksud.
Bill K

18
@pst: dengan MVP itu benar-benar 1 View = 1 Presenter. Dengan MVC, Pengontrol dapat mengatur banyak tampilan. Itu dia, sungguh. Dengan model "tab" bayangkan setiap tab memiliki Presenter sendiri sebagai lawan memiliki satu Pengendali untuk semua tab.
Jon Limjap

4
Awalnya ada dua jenis pengontrol: yang Anda katakan akan dibagikan di beberapa tampilan, dan mereka yang memiliki pandangan khusus, terutama bertujuan untuk mengadaptasi antarmuka pengontrol bersama.
Acsor

1
@JonLimjap Apa maksudnya dengan satu tampilan? Dalam konteks pemrograman iOS, apakah ini satu layar? Apakah ini membuat pengontrol iOS lebih seperti MVP daripada MVC? (Di sisi lain Anda juga dapat memiliki beberapa pengontrol iOS per layar)
huggie

2
Ilustrasi Diagram Well Todd tentang MVC sepenuhnya bertentangan dengan ide decoupling View dan Model. Jika Anda melihat diagram, ia mengatakan Model pembaruan View (panah dari Model ke View). Di mana alam semesta adalah sistem, di mana Model secara langsung berinteraksi dengan View, yang dipisahkan ???
Ash

260

Berikut adalah ilustrasi yang mewakili aliran komunikasi

masukkan deskripsi gambar di sini

masukkan deskripsi gambar di sini


44
Saya punya pertanyaan tentang diagram MVC. Saya tidak mendapatkan bagian di mana tampilan keluar untuk mengambil data. Saya akan berpikir controller akan meneruskan ke tampilan dengan data yang dibutuhkan.
Brian Rizo

54
Jika pengguna mengklik tombol, bagaimana itu tidak berinteraksi dengan tampilan? Saya merasa seperti di MVC, pengguna berinteraksi dengan tampilan lebih dari pengontrol
Jonathan

5
Saya tahu ini adalah jawaban lama - tetapi adakah yang bisa menanggapi pada titik @JonathanLeaders? Saya datang dari latar belakang winforms kecuali Anda melakukan pengkodean yang sangat unik, ketika Anda mengklik UI / View mengetahui tentang klik itu sebelum hal lainnya. Setidaknya, sejauh yang saya tahu?
Rob P.

6
@RobP. Saya pikir jenis grafik ini selalu cenderung terlalu kompleks, atau terlalu sederhana. Selain itu, bagan MVP juga berlaku untuk aplikasi MVC. Mungkin ada variasi, tergantung pada fitur bahasa (pengikatan / pengamat data), tetapi pada akhirnya idenya adalah untuk memisahkan pandangan dari data / logika aplikasi.
Luca Fülbier

15
@ JonathanLeaders Orang-orang memiliki hal yang sangat berbeda dalam pikiran ketika mereka mengatakan "MVC". Orang yang membuat bagan ini mungkin mempertimbangkan MVC Web klasik, di mana "input pengguna" adalah permintaan HTTP, dan "tampilan dikembalikan ke pengguna" adalah laman HTML yang dirender. Jadi interaksi apa pun antara pengguna dan tampilan "tidak ada" dari perspektif penulis aplikasi Web MVC klasik.
cubuspl42

170

MVP belum tentu merupakan skenario di mana View bertanggung jawab (lihat MVP Taligent misalnya).
Saya merasa sangat disayangkan bahwa orang-orang masih mengkhotbahkan ini sebagai sebuah pola (Lihat bertanggung jawab) sebagai lawan dari anti-pola karena bertentangan dengan "Itu hanya sebuah pandangan" (Pragmatic Programmer). "Ini hanya tampilan" menyatakan bahwa tampilan akhir yang ditampilkan kepada pengguna adalah perhatian kedua dari aplikasi. Pola MVP Microsoft membuat penggunaan kembali Tampilan jauh lebih sulit dan nyaman alasan desainer Microsoft mendorong praktik buruk.

Sejujurnya, saya pikir keprihatinan yang mendasari MVC berlaku untuk setiap implementasi MVP dan perbedaannya hampir seluruhnya 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 mendasarinya)) maka Anda mencapai manfaat MVC . Jika Anda mencapai manfaatnya, lalu siapa yang benar-benar peduli apakah pola Anda adalah MVC, MVP atau Pengawas Pengawas? Satu-satunya pola nyata tetap sebagai MVC, sisanya hanya rasa yang berbeda.

Pertimbangkan ini artikel yang sangat menarik yang komprehensif daftar sejumlah tersebut implementasi yang berbeda. Anda mungkin memperhatikan bahwa mereka semua pada dasarnya melakukan hal yang sama tetapi sedikit berbeda.

Saya pribadi berpikir MVP baru-baru ini diperkenalkan kembali sebagai istilah yang menarik untuk mengurangi argumen antara fanatik semantik yang berdebat apakah sesuatu benar-benar MVC atau tidak atau untuk membenarkan alat Pengembangan Aplikasi Cepat Microsoft. Tak satu pun dari alasan-alasan ini dalam buku-buku saya membenarkan keberadaannya sebagai pola desain yang terpisah.


28
Saya telah membaca beberapa jawaban dan blog tentang perbedaan antara MVC / MVP / MVVM / etc '. Akibatnya, ketika Anda sedang dalam urusan bisnis, semuanya tetap sama. Tidak masalah apakah Anda memiliki antarmuka atau tidak, dan apakah Anda menggunakan setter (atau fitur bahasa lainnya). Tampak bahwa perbedaan antara pola-pola ini lahir dari perbedaan implementasi berbagai kerangka kerja, bukan masalah konsep.
Michael

6
Saya tidak akan menyebut MVP sebagai anti-pola , seperti pada posting selanjutnya ".. sisanya [termasuk MVP] hanya berbeda rasa [MVC] ..", yang akan menyiratkan bahwa jika MVP adalah anti-pola, maka adalah MVC ... itu hanya rasa untuk pendekatan kerangka kerja yang berbeda. (Sekarang, beberapa implementasi MVP tertentu mungkin lebih atau kurang diinginkan daripada beberapa implementasi MVC tertentu untuk tugas yang berbeda ...)

@ Quibblsome: "Saya pribadi berpikir MVP baru-baru ini diperkenalkan kembali sebagai istilah yang menarik untuk mengurangi argumen antara fanatik semantik yang berdebat apakah sesuatu itu benar-benar MVC atau tidak [...] Tidak satu pun dari alasan ini dalam buku saya yang membenarkan keberadaannya sebagai pola desain yang terpisah. " . Cukup berbeda untuk membuatnya berbeda. Dalam MVP, tampilan bisa berupa apa saja yang memenuhi antarmuka yang telah ditentukan (Tampilan dalam MVP adalah komponen mandiri). Dalam MVC, Pengendali dibuat untuk tampilan tertentu (jika hubungan arities dapat membuat seseorang merasa itu layak istilah lain).
Hibou57

6
@ Hibou57, tidak ada yang menghentikan MVC dari merujuk tampilan sebagai antarmuka atau membuat pengendali generik untuk beberapa tampilan berbeda.
Quibblesome

1
Samuel tolong jelaskan apa yang Anda bicarakan. Kecuali jika Anda memberi tahu saya sejarah tim yang "menemukan" MVC maka saya sangat meragukan teks Anda. Jika Anda hanya berbicara tentang WinForm maka ada cara lain dalam melakukan sesuatu dan saya telah membuat proyek WinForm di mana binding kontrol dikelola oleh pengontrol, bukan "kontrol individu".
Quibblesome

110

MVP: tampilan ini bertanggung jawab.

Pandangan, dalam banyak kasus, menciptakan presenternya. Presenter akan berinteraksi dengan model dan memanipulasi tampilan melalui antarmuka. Pandangan kadang-kadang akan berinteraksi dengan presenter, biasanya melalui beberapa antarmuka. Ini adalah implementasi; apakah Anda ingin view memanggil metode pada presenter atau Anda ingin view memiliki acara yang didengarkan presenter? Intinya begini: Pandangan tahu tentang presenter. Tampilan mendelegasikan ke presenter.

MVC: controller bertanggung jawab.

Pengontrol dibuat atau diakses berdasarkan beberapa peristiwa / permintaan. Pengontrol kemudian membuat tampilan yang sesuai dan berinteraksi dengan model untuk lebih lanjut mengkonfigurasi tampilan. Itu bermuara pada: controller menciptakan dan mengelola tampilan; tampilan adalah slave ke controller. Pandangan tidak tahu tentang controller.


3
"Pandangan tidak tahu tentang Kontroler." Saya pikir maksud Anda pandangan tidak memiliki kontak langsung dengan model?
Lotus Notes

2
pandangan tidak boleh tahu tentang model di eiether one.
Brian Leahy

4
@Brian: "The View, dalam banyak kasus, menciptakan Presenter-nya." . Saya kebanyakan melihat yang sebaliknya, dengan Presenter meluncurkan Model dan View. Yah, View mungkin meluncurkan Presenter juga, tapi poin itu sebenarnya bukan yang paling khas. Yang paling penting terjadi kemudian selama masa hidup.
Hibou57

2
Anda mungkin ingin mengedit jawaban Anda untuk menjelaskan lebih lanjut: Karena View tidak tahu tentang Controller, bagaimana tindakan pengguna, yang dilakukan pada elemen 'visual' yang dilihat pengguna di layar (yaitu View), dikomunikasikan ke Controller ...
Ash

77

masukkan deskripsi gambar di sini

MVC (Pengendali Tampilan Model)

Input diarahkan pada Controller terlebih dahulu, bukan tampilan. Input itu mungkin berasal dari pengguna yang berinteraksi dengan halaman, tetapi bisa juga dengan memasukkan url tertentu ke browser. Dalam kedua kasus, ini adalah Controller yang dihubungkan dengan untuk memulai beberapa fungsi. Ada banyak-ke-satu hubungan antara Pengendali dan Tampilan. Itu karena pengontrol tunggal dapat memilih tampilan yang berbeda untuk diberikan berdasarkan operasi yang sedang dijalankan. Perhatikan panah satu arah dari Controller ke View. Ini karena View tidak memiliki pengetahuan atau referensi ke controller. Controller memang melewatkan kembali Model, jadi ada pengetahuan antara View dan Model yang diharapkan diteruskan ke dalamnya, tetapi tidak Controller yang menyajikannya.

MVP (Model View Presenter)

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

Untuk Referensi lebih lanjut


Tetapi dalam MVPpola, ketika aplikasi memuat untuk pertama kalinya, bukankah presenter bertanggung jawab untuk memuat tampilan pertama? Seperti misalnya ketika kita memuat aplikasi facebook, bukankah presenter bertanggung jawab untuk memuat halaman login?
viper

2
Tautan dari Model ke Lihat di MVC? Anda mungkin ingin mengedit jawaban Anda untuk menjelaskan bagaimana ini membuatnya menjadi sistem 'dipisahkan', diberikan tautan ini. Petunjuk: Anda mungkin merasa sulit. Selain itu, kecuali jika Anda berpikir bahwa pembaca akan dengan senang hati menerima bahwa mereka telah salah menghitung sepanjang hidup mereka, Anda mungkin ingin menguraikan mengapa tindakan melalui Controller terlebih dahulu di MVC meskipun pengguna berinteraksi dengan elemen 'visual' di layar (yaitu View), bukan lapisan abstrak yang berada di belakang melakukan pemrosesan.
Ash

3
Ini jelas salah ... di MVC, model tidak pernah berbicara langsung dengan tampilan dan sebaliknya. Mereka bahkan tidak tahu ada yang lain. Kontroler adalah lem yang menyatukan mereka
MegaManX

1
Saya setuju dengan Ash dan MegaManX. Dalam diagram MVC, panah harus dari View yang menunjuk ke Model (atau ViewModel, atau DTO), bukan dari Model ke View; karena Model tidak tahu tentang Tampilan, tetapi tampilan mungkin tahu tentang Model.
Jboy Flaga

57

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

Pengguna: Klik klik ...

Lihat : Siapa itu? [ MVP | MVC ]

Pengguna: Saya baru saja mengklik tombol pencarian ...

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

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

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

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

Melihat : Ya, ... ini dia ... "piano" [ 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 ]

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

Model : Hey Presenter | Pengendali , izinkan saya memeriksa ... [ MVP | MVC ]

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

( Setelah beberapa saat ... )

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

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

Model : Ada beberapa hasil yang tersedia, Pengendali . Saya telah membuat variabel bidang dalam contoh saya dan mengisinya dengan hasilnya. Namanya 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"]. Tolong tunjukkan kepada pengguna dalam daftar vertikal. 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 ]

Lihat : Terima kasih banyak Presenter [ MVP ]

Lihat : Terima kasih "Kontroler" [ MVC ] (Sekarang Tampilan mempertanyakan dirinya sendiri: Bagaimana saya harus menyajikan hasil yang saya dapatkan dari Model kepada pengguna? Haruskah tahun produksi film datang pertama atau terakhir ...? Haruskah berada dalam daftar vertikal atau horizontal? ...)

Jika Anda tertarik, saya telah menulis serangkaian artikel yang berhubungan dengan pola arsitektur aplikasi (MVC, MVP, MVVP, arsitektur bersih, ...) disertai dengan repo Github di sini . Meskipun sampel ditulis untuk android, prinsip-prinsip yang mendasarinya dapat diterapkan ke media apa pun.


Pada dasarnya apa yang ingin Anda katakan adalah bahwa pengontrol mengatur pengaturan logika tampilan? Jadi itu membuat tampilan menjadi bodoh dengan menghadirkan apa yang terjadi dan bagaimana pada tampilan?
Radu

@Radu, Tidak, ini bukan mikromanage, itulah yang dilakukan presenter dengan membuat tampilan pasif atau bisu
Ali Nem

4
Dalam MVC yang tepat, tampilan memanggil fungsionalitas pada controller, dan mendengarkan perubahan data dalam model. Tampilan tidak mendapatkan data dari pengontrol, dan pengontrol TIDAK harus memberitahu tampilan untuk ditampilkan, misalnya, indikator pemuatan. MVC yang tepat memungkinkan Anda untuk mengganti bagian tampilan, dengan bagian yang secara fundamental berbeda. Bagian tampilan memegang logika tampilan, yang mencakup indikator pemuatan. Tampilan memanggil instruksi (dalam controller), controller memodifikasi data dalam model, dan model memberitahukan pendengarnya tentang perubahan data, salah satu pendengar tersebut adalah view.
Tommy Andersen

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

    1. Kedua pola presentasi. Mereka memisahkan ketergantungan antara Model (pikirkan objek Domain), layar / halaman web Anda (Tampilan), dan bagaimana UI Anda seharusnya berperilaku (Presenter / Controller)
    2. Mereka cukup mirip dalam konsep, orang menginisialisasi Presenter / Controller berbeda tergantung selera.
    3. Artikel bagus tentang perbedaan ada di sini . Yang paling penting adalah bahwa pola MVC memiliki Model yang memperbarui Tampilan.

2
Model memperbarui VIew. Dan ini masih merupakan sistem yang dipisahkan?
Ash

34

Model-View-Controller

MVC adalah pola untuk arsitektur aplikasi perangkat lunak. Ini memisahkan logika aplikasi menjadi tiga bagian yang terpisah, mempromosikan modularitas dan kemudahan kolaborasi dan penggunaan kembali. Ini juga membuat aplikasi lebih fleksibel dan ramah terhadap iterasi. Ini memisahkan aplikasi menjadi komponen-komponen berikut:

  • Model untuk menangani data dan logika bisnis
  • Pengontrol untuk menangani antarmuka pengguna dan aplikasi
  • Tampilan untuk menangani objek dan presentasi antarmuka pengguna grafis

Untuk membuatnya lebih jelas, mari kita bayangkan aplikasi daftar belanja sederhana. Yang kami inginkan adalah daftar nama, jumlah, dan harga setiap barang yang perlu kami beli minggu ini. Di bawah ini kami akan menjelaskan bagaimana kami dapat mengimplementasikan beberapa fungsi ini menggunakan MVC.

masukkan deskripsi gambar di sini

Model-View-Presenter

  • The model adalah data yang akan ditampilkan dalam tampilan (user interface).
  • The tampilan adalah sebuah antarmuka yang menampilkan data (model) dan perintah-rute user (peristiwa) ke Presenter untuk bertindak atas data tersebut. Tampilan biasanya memiliki referensi ke Presenter-nya.
  • The Presenter adalah “tengah-manusia” (diperankan oleh controller di MVC) dan memiliki referensi untuk keduanya, pandangan dan model. Harap dicatat bahwa kata "Model" menyesatkan. Seharusnya logika bisnis yang mengambil atau memanipulasi Model . Misalnya: Jika Anda memiliki database yang menyimpan Pengguna dalam tabel database dan View Anda ingin menampilkan daftar pengguna, maka Presenter akan memiliki referensi ke logika bisnis database Anda (seperti DAO) dari mana Presenter akan menanyakan daftar. Pengguna.

Jika Anda ingin melihat sampel dengan implementasi sederhana, silakan periksa pos GitHub ini

Alur kerja yang konkret untuk menanyakan dan menampilkan daftar pengguna dari basis data dapat berfungsi seperti ini: masukkan deskripsi gambar di sini

Apa perbedaan antara pola MVC dan MVP ?

Pola MVC

  • Pengontrol didasarkan pada perilaku dan dapat dibagi lintas pandangan

  • Dapat bertanggung jawab untuk menentukan tampilan mana yang akan ditampilkan (Pola Pengontrol Depan)

Pola MVP

  • Tampilan lebih longgar digabungkan ke model. Presenter bertanggung jawab untuk mengikat model ke tampilan.

  • Lebih mudah untuk unit test karena interaksi dengan tampilan adalah melalui antarmuka

  • Biasanya melihat ke presenter peta satu ke satu. Tampilan kompleks mungkin memiliki banyak penyaji.


2
nah, tidak ada koneksi langsung antara tampilan dan model di MVC. diagram Anda salah.
Özgür

33

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

Saat menggunakan Tampilan Pasif, Tampilan Anda biasanya menerapkan antarmuka berbutir 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 "Pandangan Pasif". Keuntungannya adalah tampilan mudah untuk diuji, dan lebih mudah untuk berpindah antar platform UI (Web, Windows / XAML, dll.). Kerugiannya adalah Anda tidak dapat memanfaatkan hal-hal seperti penyatuan data (yang sangat kuat dalam kerangka kerja seperti WPF dan Silverlight ).

Rasa kedua dari MVP adalah Pengawas Pengawas. Dalam hal itu, View Anda mungkin memiliki properti yang disebut Pelanggan, yang sekali lagi adalah databound ke widget UI. Anda tidak harus berpikir tentang menyinkronkan dan mengelola mikro tampilan, dan Pengawas Pengawas dapat masuk dan membantu ketika diperlukan, misalnya dengan logika interaksi yang telah dibuat.

"Rasa" MVP ketiga (atau seseorang mungkin menyebutnya pola yang terpisah) adalah Model Presentasi (atau kadang-kadang disebut Model-View-ViewModel). Dibandingkan dengan MVP Anda "menggabungkan" M dan P menjadi satu kelas. Anda memiliki objek pelanggan yang terikat dengan widget UI, tetapi Anda juga memiliki bidang khusus UI tambahan 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 membahas semua rasa MVP dan menunjukkan kode C # untuk mengimplementasikannya.

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


25

Mereka masing-masing mengatasi masalah yang berbeda dan bahkan dapat digabungkan bersama untuk memiliki sesuatu seperti di bawah ini

Pola Gabungan

Ada juga perbandingan lengkap MVC, MVP dan MVVM di sini


1
Alih-alih hal yang terlalu rumit, Anda bisa menjawab pertanyaan itu. Itu sebabnya mayoritas dari kita ada di sini. Mencari perbandingan antara mvp dan mvc dan dialihkan ke sini dan Anda sedang berbicara tentang keharmonisan arsitektur yang tidak terkait dengan OP.
Farid

18

Kedua kerangka kerja ini bertujuan untuk memisahkan masalah - misalnya, interaksi dengan sumber data (model), logika aplikasi (atau mengubah data ini menjadi informasi yang bermanfaat) (Kontroler / Presenter) dan kode tampilan (Tampilan). Dalam beberapa kasus model juga dapat digunakan untuk mengubah sumber data menjadi abstraksi tingkat yang lebih tinggi juga. Contoh yang baik dari ini adalah proyek MVC Storefront .

Ada diskusi di sini mengenai perbedaan antara MVC vs MVP.

Perbedaan yang dibuat adalah bahwa dalam aplikasi MVC secara tradisional memiliki pandangan dan pengontrol berinteraksi dengan model, tetapi tidak satu sama lain.

Desain MVP membuat Presenter mengakses model dan berinteraksi dengan tampilan.

Karena itu, ASP.NET MVC dengan definisi ini kerangka kerja MVP karena Pengendali mengakses Model untuk mengisi Lihat yang dimaksudkan untuk tidak memiliki logika (hanya menampilkan variabel yang disediakan oleh Pengendali).

Untuk mungkin mendapatkan gambaran tentang perbedaan ASP.NET MVC dari MVP, lihat presentasi MIX ini oleh Scott Hanselman.


7
MVC dan MVP adalah pola, bukan kerangka kerja. Jika Anda berpikir dengan jujur, topik itu adalah tentang .NET framework, maka itu seperti mendengarkan "internet" dan berpikir tentang IE.
tereško

Cukup yakin pertanyaannya telah berevolusi secara signifikan sejak pertama kali ditanyakan kembali pada tahun 2008. Selain itu, melihat kembali jawaban saya (dan ini adalah 4 tahun yang lalu jadi saya tidak memiliki lebih banyak konteks daripada Anda) Saya akan mengatakan saya mulai secara umum dan kemudian gunakan .NET MVC sebagai contoh nyata.
Matt Mitchell

13

Keduanya adalah pola yang berusaha memisahkan presentasi dan logika bisnis, memisahkan logika bisnis dari aspek UI

Secara arsitektur, MVP adalah pendekatan berbasis Halaman Controller di mana MVC adalah pendekatan berbasis Front Controller. Itu berarti bahwa dalam siklus hidup halaman bentuk web standar MVP hanya ditingkatkan dengan mengekstraksi logika bisnis dari kode di belakang. Dengan kata lain, halaman adalah satu-satunya permintaan layanan http. Dengan kata lain, MVP IMHO adalah jenis peningkatan bentuk evolusi web. MVC di sisi lain sepenuhnya mengubah permainan karena permintaan akan dicegat oleh kelas pengontrol sebelum halaman dimuat, logika bisnis dijalankan di sana dan kemudian pada hasil akhir pengontrol memproses data yang baru saja dibuang ke halaman ("view"). akal, MVC terlihat (setidaknya bagi saya) banyak rasa Pengawas Pengawasan MVP ditingkatkan dengan mesin routing

Keduanya memungkinkan TDD dan memiliki kelemahan dan kelebihan.

Keputusan tentang bagaimana memilih salah satu dari mereka IMHO harus didasarkan pada berapa banyak waktu yang diinvestasikan dalam jenis web ASP bentuk pengembangan web. Jika seseorang menganggap dirinya bagus dalam bentuk web, saya sarankan MVP. Jika seseorang merasa tidak begitu nyaman dalam hal-hal seperti siklus hidup halaman, dll. MVC bisa menjadi cara untuk pergi ke sini.

Berikut ini lagi tautan posting blog yang memberikan sedikit detail tentang topik ini

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx


9

Saya telah menggunakan MVP dan MVC dan meskipun kami sebagai pengembang cenderung fokus pada perbedaan teknis kedua pola, titik untuk MVP di IMHO jauh lebih terkait dengan kemudahan adopsi daripada hal lainnya.

Jika saya bekerja di tim yang sudah memiliki latar belakang yang baik tentang gaya pengembangan bentuk web, jauh lebih mudah untuk memperkenalkan MVP daripada MVC. Saya akan mengatakan bahwa MVP dalam skenario ini adalah kemenangan cepat.

Pengalaman saya memberi tahu saya bahwa memindahkan tim dari formulir web ke MVP dan kemudian dari MVP ke MVC relatif mudah; pindah dari formulir web ke MVC lebih sulit.

Saya meninggalkan di sini tautan ke serangkaian artikel yang telah diterbitkan teman saya tentang MVP dan MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx


8

Dalam MVP tampilan menarik data dari presenter yang menggambar dan menyiapkan / menormalkan data dari model sementara di MVC pengontrol mengambil data dari model dan mengatur, dengan menekan tampilan.

Di MVP Anda dapat memiliki satu tampilan yang bekerja dengan beberapa jenis presenter dan satu presenter yang bekerja dengan beberapa tampilan berbeda.

MVP biasanya menggunakan semacam kerangka kerja mengikat, seperti kerangka kerja mengikat Microsoft WPF atau berbagai kerangka kerja mengikat untuk HTML5 dan Java.

Dalam kerangka tersebut, UI / HTML5 / XAML, mengetahui properti apa yang ditampilkan oleh presenter yang ditampilkan oleh setiap elemen UI, jadi ketika Anda mengikat tampilan ke presenter, tampilan mencari properti dan tahu cara menggambar data dari mereka dan bagaimana untuk mengatur mereka ketika nilai diubah di UI oleh pengguna.

Jadi, jika misalnya, modelnya adalah mobil, maka presenter adalah semacam presenter mobil, memperlihatkan sifat-sifat mobil (tahun, pembuat, tempat duduk, dll.) Ke tampilan. Pandangan tahu bahwa bidang teks yang disebut 'pembuat mobil' perlu menampilkan properti pembuat presenter.

Anda kemudian dapat mengikat pandangan berbagai jenis presenter, semua harus memiliki properti Maker - bisa dari pesawat, kereta api atau apa pun, pemandangan tidak peduli. Tampilan menarik data dari presenter - tidak peduli yang mana - asalkan mengimplementasikan antarmuka yang disepakati.

Kerangka kerja yang mengikat ini, jika Anda melepasnya, itu sebenarnya controller :-)

Jadi, Anda dapat melihat MVP sebagai evolusi MVC.

MVC memang bagus, tetapi masalahnya adalah biasanya controller-nya per view. Controller A tahu cara mengatur bidang View A. Jika sekarang, Anda ingin View A untuk menampilkan data model B, Anda perlu Controller A untuk mengetahui model B, atau Anda perlu Controller A untuk menerima objek dengan antarmuka - yang seperti MVP hanya tanpa binding, atau Anda perlu menulis ulang kode set UI di Controller B.

Kesimpulan - MVP dan MVC keduanya decouple dari pola UI, tetapi MVP biasanya menggunakan kerangka binding yang merupakan MVC di bawahnya. MVP INI berada pada tingkat arsitektur yang lebih tinggi daripada MVC dan pola pembungkus di atas MVC.


6

Pandangan singkat saya yang sederhana: MVP adalah untuk skala besar, dan MVC untuk skala kecil. Dengan MVC, kadang-kadang saya merasa V dan C dapat dilihat sebagai dua sisi dari satu komponen yang tidak dapat dipisahkan yang secara langsung terikat pada M, dan satu yang pasti jatuh ke ini ketika turun ke skala yang lebih pendek, seperti kontrol UI dan widget dasar. Pada tingkat granularitas ini, MVP tidak masuk akal. Ketika seseorang sebaliknya pergi ke skala yang lebih besar, antarmuka yang tepat menjadi lebih penting, sama dengan penugasan tanggung jawab yang jelas, dan inilah MVP.

Di sisi lain, aturan skala praktis ini, mungkin berbobot sangat kecil ketika karakteristik platform lebih menyukai semacam hubungan antara komponen, seperti dengan web, di mana tampaknya lebih mudah untuk mengimplementasikan MVC, lebih dari MVP.


4

Saya pikir gambar ini oleh Erwin Vandervalk (dan artikel yang menyertainya ) adalah penjelasan terbaik tentang MVC, MVP, dan MVVM, kesamaan mereka, dan perbedaan mereka. The Artikel tidak muncul dalam hasil mesin pencari untuk query pada "MVC, MVP, dan MVVM" karena judul artikel tidak mengandung kata-kata "MVC" dan "MVP"; tapi itu penjelasan terbaik, saya pikir.

gambar menjelaskan MVC, MVP dan MVVM - oleh Erwin Vandervalk

( Artikel ini juga cocok dengan apa yang dikatakan Paman Bob Martin dalam salah satu ceramahnya: bahwa MVC pada awalnya dirancang untuk komponen UI kecil, bukan untuk arsitektur sistem)


3

Ada banyak versi MVC, jawaban ini adalah tentang MVC asli di Smalltalk. Singkatnya, itu gambar dari mvc vs mvp

Pembicaraan ini droidcon NYC 2017 - Desain aplikasi bersih dengan Komponen Arsitektur mengklarifikasi itu

masukkan deskripsi gambar di sini masukkan deskripsi gambar di sini


6
Dalam MVC Model tidak pernah dipanggil langsung dari tampilan
rodi

5
Ini adalah jawaban yang tidak akurat. Jangan disesatkan. seperti yang ditulis @rodi, tidak ada interaksi antara View dan Model.
Shawn Mehan

Gambar MVC tidak akurat atau paling tidak menyesatkan, harap tidak memperhatikan jawaban ini.
Jay

2
@ Jay1b Menurutmu MVC apa yang "benar"? Jawaban ini tentang MVC asli. Ada banyak MVC lain (seperti di iOS) yang diubah untuk beradaptasi dengan platform, katakan sepertiUIKit
onmyway133

Apa arti panah?
problemofficer

3

Ada ini video yang bagus dari Paman Bob di mana ia menjelaskan secara singkat MVC & MVP di akhir.

IMO, MVP adalah versi perbaikan MVC di mana Anda pada dasarnya memisahkan kekhawatiran tentang apa yang akan Anda tunjukkan (data) dari bagaimana Anda akan menunjukkan (tampilan). Presenter menyertakan sedikit logika bisnis UI Anda, secara implisit memaksakan data apa yang harus disajikan dan memberi Anda daftar model tampilan bodoh. Dan ketika tiba saatnya untuk menunjukkan data, Anda cukup mencolokkan tampilan Anda (mungkin termasuk id yang sama) ke adaptor Anda dan mengatur bidang tampilan yang relevan menggunakan model tampilan tersebut dengan jumlah minimum kode yang diperkenalkan (hanya menggunakan setter). Manfaat utamanya adalah Anda dapat menguji logika bisnis UI Anda terhadap banyak / berbagai tampilan seperti menampilkan item dalam daftar horizontal atau daftar vertikal.

Dalam MVC, kita berbicara melalui antarmuka (batas) untuk merekatkan lapisan yang berbeda. Pengontrol adalah plug-in untuk arsitektur kita tetapi tidak memiliki batasan untuk memaksakan apa yang ditampilkan. Dalam pengertian itu, MVP adalah sejenis MVC dengan konsep pandangan yang dapat dipasang ke controller melalui adaptor.

Saya harap ini membantu lebih baik.


2
Poin penting dari Paman Bob: Ketika awalnya ditemukan oleh Trygve Reenskaug, MVC dimaksudkan untuk setiap widget, bukan seluruh formulir.
Basil Bourque

2

Anda lupa tentang Action-Domain-Responder ( ADR ).

Sebagaimana dijelaskan dalam beberapa gambar di atas, ada hubungan / tautan langsung antara Model dan Tampilan di MVC. Suatu tindakan dilakukan pada Controller , yang akan mengeksekusi aksi pada Model . Tindakan itu dalam Model , akan memicu reaksi dalam Tampilan . The View , selalu diperbarui ketika Model perubahan negara.

Beberapa orang terus lupa, bahwa MVC diciptakan pada akhir 70 " , dan bahwa Web hanya dibuat pada akhir 80" / awal 90 ". MVC pada awalnya tidak dibuat untuk Web, tetapi untuk aplikasi Desktop, di mana Pengontrol , Model dan View akan hidup berdampingan bersama.

Karena kami menggunakan kerangka kerja web ( mis .: Laravel ) yang masih menggunakan konvensi penamaan yang sama ( model-view-controller ), kami cenderung berpikir bahwa itu pasti MVC, tetapi sebenarnya ini adalah sesuatu yang lain.

Sebaliknya, lihat Action-Domain-Responder . Dalam ADR, Pengendali mendapat Tindakan , yang akan melakukan operasi di Model / Domain . Sejauh ini, sama saja. Perbedaannya adalah, ia kemudian mengumpulkan respons / data operasi itu, dan meneruskannya ke Responder ( misalnya :.view() ) untuk rendering. Ketika tindakan baru diminta pada komponen yang sama, Pengontrol dipanggil lagi, dan siklus berulang. Di ADR, tidak ada koneksi antara Model / Domain dan View ( Tanggapan Reponser ).

Catatan: Wikipedia menyatakan bahwa " Setiap tindakan ADR, bagaimanapun, diwakili oleh kelas atau penutupan yang terpisah. ". Ini belum tentu benar. Beberapa Tindakan bisa di Kontroler yang sama, dan polanya masih sama.


2

Jawaban paling sederhana adalah bagaimana tampilan berinteraksi dengan model. Dalam MVP tampilan diperbarui oleh presenter, yang bertindak sebagai perantara antara tampilan dan model. Presenter mengambil input dari tampilan, yang mengambil data dari model dan kemudian melakukan logika bisnis apa pun yang diperlukan dan kemudian memperbarui tampilan. Dalam MVC model memperbarui tampilan secara langsung daripada kembali melalui pengontrol.


Saya telah downvoted, karena afaik model tidak tahu apa-apa tentang tampilan di MVC dan tidak ada dapat memperbaruinya secara langsung saat Anda menulis.
problemofficer

1
Lihatlah MVC di Wikipedia, itulah cara kerjanya.
Clive Jefferies

1
Apakah pembaca suka atau tidak, banyak sumber yang dapat ditemukan dengan googling menyatakan bahwa dalam MVC tampilan berlangganan pembaruan pada model. dan dalam beberapa kasus bahkan mungkin menjadi pengontrol dan karenanya meminta pembaruan semacam itu. Jika Anda tidak suka itu, pergilah mengeluh pada artikel-artikel itu, atau kutip mana 'alkitab' yang Anda anggap sebagai satu-satunya sumber yang sah, alih-alih menjawab downvoting yang hanya menyampaikan info lain yang tersedia di luar sana!
underscore_d

1
Kata-katanya pasti dapat ditingkatkan, tetapi memang benar bahwa pandangan berlangganan perubahan dalam model di MVC. Model tidak perlu tahu View di MVC.
melahap elysium

terima kasih..Itu banyak membantu saya
Dvyn Resh

1
  • Dalam MVC, View memiliki bagian UI, controller adalah mediator antara view dan model & model berisi logika bisnis.
  • Dalam MVP, View mengandung UI dan implementasi presenter karena di sini presenter hanyalah antarmuka & model yang sama yaitu berisi logika bisnis.

-1

MVP

MVP adalah singkatan dari Model - View- Presenter. Ini muncul pada gambar di awal 2007 di mana Microsoft memperkenalkan aplikasi Smart Client windows.

Presenter bertindak sebagai peran pengawas di MVP yang mengikat Lihat acara dan logika bisnis dari model.

Penjilidan acara lihat akan diterapkan di Presenter dari antarmuka tampilan.

Tampilan adalah inisiator untuk input pengguna dan kemudian mendelegasikan acara ke Presenter dan presenter menangani binding acara dan mendapatkan data dari model.

Kelebihan: Tampilan hanya memiliki UI dan tidak ada logika

Cons: Agak rumit dan lebih banyak pekerjaan ketika menerapkan binding acara

MVC

MVC adalah singkatan dari Model-View-Controller. Pengontrol bertanggung jawab untuk membuat model dan menampilkan tampilan dengan model yang mengikat.

Kontroler adalah penggagas dan memutuskan pandangan mana yang akan ditampilkan.

Kelebihan: Penekanan pada Prinsip Tanggung Jawab Tunggal Tingkat testabilitas yang tinggi

Cons: Terkadang terlalu banyak beban kerja untuk Controllers, jika mencoba merender banyak view dalam controller yang sama.

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.