MVC vs MVP vs MVVM: Penjelasan pola arsitektur Android yang umum

Saat bekerja sebagai developer, Anda pasti pernah mendengar tentang pola arsitektur. Di dunia Android kami, yang paling dikenal adalah MVC , MVP dan MVVM . Anda mungkin tahu karakteristiknya, tetapi apakah Anda tahu perbedaannya dan kapan menggunakannya?

Jika Anda bertanya pada diri sendiri pertanyaan-pertanyaan ini, artikel ini adalah untuk Anda.

MVC – Model-View-Controller

Model-View-Controller (MVC) adalah pola arsitektur yang membantu mengatur struktur aplikasi kita. Ini membagi tanggung jawabnya menjadi tiga lapisan: Model, View, dan Controller.

Butuh pakar Android?

Bekerja dengan kami!

• Model – Lapisan data, bertanggung jawab untuk mengelola logika bisnis dan mendukung jaringan atau database API. Model bekerja dengan sumber data jarak jauh dan lokal untuk mendapatkan dan menyimpan data. Di sinilah logika bisnis ditangani.
• View – Lapisan UI, bertanggung jawab untuk visualisasi data dari Model ke pengguna. Ini mengelola cara data disajikan, termasuk antarmuka grafis.
• Controller – Sebuah lapisan logis yang mengintegrasikan lapisan View dan Model. Tugas Pengendali adalah mengambil alih input pengguna dan menentukan apa yang harus dilakukan dengannya.

Anda dapat dengan cepat melihat bagaimana masing-masing komponen berkomunikasi dalam grafik di bawah ini:

Bagaimana itu bekerja?

Beberapa varian MVC telah muncul selama bertahun-tahun, tetapi saya akan menyebutkan dua yang paling populer di sini: model Pasif dan model Aktif.

Model Pasif

Dalam versi MVC ini, Controller adalah satu-satunya kelas yang memanipulasi Model. Untuk menggambarkan proses ini dengan baik, saya akan menggunakan grafik di bawah ini:

1. Controller merespon tindakan pengguna dan menghubungi Model.
2. Ketika Model diubah, Controller memberitahu View untuk memperbarui datanya.
3. Tampilan mengambil data yang diperbarui dari Model dan menampilkannya kepada pengguna.

Model Aktif

Dalam versi MVC ini, kelas lain selain Controller memanipulasi Model.

Dalam hal ini, pola Pengamat digunakan, dan Tampilan didaftarkan sebagai Pengamat Model. Berkat ini, Tampilan akan terus diperbarui ketika Model berubah.

Keuntungan

1. Pola MVC sangat mendukung masalah pemisahan. Ini meningkatkan testabilitas kode dan memfasilitasi ekstensi, memungkinkan implementasi fungsi baru dengan mudah.
2. Kelas Model tidak memiliki referensi ke kelas sistem Android, sehingga sangat mudah untuk menguji unit.
3. Pengontrol tidak memperluas atau mengimplementasikan kelas Android apa pun. Itu memungkinkan pengujian unit.

Kekurangan

1. View berhubungan dengan Controller dan Model.
   • Ketergantungan Tampilan pada Model terutama menyebabkan masalah pada Tampilan lanjutan. Mengapa? Jika peran Model adalah menyediakan data mentah, maka Tampilan akan mengambil alih penanganan logika antarmuka pengguna.
     Di sisi lain, jika Model akan menampilkan data yang disiapkan langsung untuk ditampilkan, kita akan mendapatkan Model yang mendukung logika bisnis dan logika UI.
   • Implementasi aktif Model meningkatkan jumlah kelas dan metode secara eksponensial karena pengamat harus diperlukan untuk setiap tipe data.
   • Saat Tampilan bergantung pada Pengontrol dan Model, perubahan pada logika UI mungkin memerlukan pembaruan/perubahan pada beberapa kelas, sehingga mengurangi fleksibilitas pola.
2. Penanganan logika UI tidak terbatas pada satu kelas. Untuk programmer baru, ini cukup menjadi masalah, dan peluang untuk pembagian tanggung jawab antara Model, View dan Controller sangat tinggi.
3. Seiring waktu, terutama dalam aplikasi dengan model anemia, semakin banyak kode mulai dikirim ke pengontrol , membuatnya membengkak dan rapuh.

Ringkasan

Ketergantungan View pada Model dan memiliki logika dalam View dapat secara signifikan menurunkan kualitas kode dalam aplikasi kita. Kita dapat mengurangi bahaya ini dengan memilih pola lain, terutama yang disarankan untuk aplikasi seluler. Baca tentang mereka di bawah ini.

MVP – Model-View-Presenter

Model-View-Presenter (MVP) adalah pola arsitektur yang dapat kita gunakan untuk mengatasi kelemahan pola MVC. Ini memberikan modularitas, kemampuan uji, dan basis kode yang jauh lebih jelas dan lebih mudah untuk dipelihara.

MVP membagi struktur aplikasi ke dalam lapisan View , Model dan Presenter :

• Model – Secara analog dengan pola MVC.
• View – Lapisan UI, bertanggung jawab untuk menyajikan data kepada pengguna dengan cara yang ditentukan oleh Presenter. Itu dapat diimplementasikan oleh Aktivitas, Fragmen, atau tampilan umum apa pun.
• Presenter – Lapisan logika yang menengahi antara lapisan View dan Model. Ini menghubungi lapisan View dan Model dan bereaksi terhadap tindakan yang dilakukan oleh pengguna.

Bagaimana itu bekerja?

Di MVP , View dan Presenter sepenuhnya terpisah dan berkomunikasi satu sama lain melalui abstraksi. Kelas antarmuka Kontrak mendefinisikan hubungan di antara mereka. Berkat mereka, kode lebih mudah dibaca, dan koneksi antar lapisan mudah dimengerti. Jika Anda tertarik dengan detail implementasi, harap baca Model-View-Presenter: Pedoman Android.

Perlu disebutkan bahwa Presenter tidak dapat memiliki referensi ke API khusus Android.

Lihat gambar di bawah untuk gambaran yang baik dari proses pertukaran data antara komponen individu. Untuk keperluan artikel ini, contoh ini disederhanakan:

1. Pengguna melakukan tindakan.
2. Presenter bereaksi terhadap tindakan pengguna dan mengirimkan permintaan yang sesuai ke Model.
3. Model diperbarui, dan data baru dikirim ke Presenter.
4. Presenter menyiapkan data untuk ditampilkan dan mengirimkannya ke View.
5. Tampilan menampilkan data kepada pengguna.

Keuntungan

1. Kami dapat dengan mudah menguji logika Presenter karena tidak terikat dengan tampilan dan API khusus Android.
2. View dan Presenter sepenuhnya terpisah , yang membuat mengejek tampilan menjadi mudah, membuat pengujian unit lebih dangkal daripada di MVC
3. Kami hanya memiliki satu kelas yang menangani segala sesuatu yang berhubungan dengan presentasi tampilan – Presenter.

Kekurangan

1. Presenter, seperti Controller, cenderung mengakumulasi logika bisnis tambahan. Untuk mengatasi masalah ini, pecahkan kode Anda dan ingatlah untuk membuat kelas hanya dengan satu tanggung jawab.
2. Meskipun ini adalah pola yang bagus untuk aplikasi Android, ini bisa terasa luar biasa saat mengembangkan aplikasi atau prototipe kecil .

Ringkasan

Dibandingkan dengan MVC, pola ini jauh lebih baik. Ini memecahkan dua masalah kritis dari pola MVC:

1. View tidak lagi mengacu pada Controller dan Model.
2. Ini hanya memiliki satu kelas yang menangani segala sesuatu yang berhubungan dengan tampilan presentasi: Presenter.

MVVM – Model-View-ViewModel

Model-View-ViewModel (MVVM) adalah pola berbasis peristiwa. Berkat ini, kami dapat bereaksi dengan cepat terhadap perubahan desain. Pola arsitektur ini memungkinkan kita untuk memisahkan UI dari logika bisnis dan perilaku bahkan lebih daripada dalam kasus MVC atau MVP.

• ViewModel – Berurusan dengan pengiriman data dari Model ke lapisan View dan menangani tindakan pengguna. Perlu disebutkan bahwa ini menyediakan aliran data untuk View.
• Tampilan – Lapisan UI bertanggung jawab untuk menyajikan data, status sistem, dan operasi saat ini dalam antarmuka grafis. Selain itu, ia menginisialisasi dan mengikat ViewModel dengan elemen View (menginformasikan ViewModel tentang tindakan pengguna).
• Model – Sama seperti MVC – tidak ada perubahan.

Bagaimana itu bekerja?

Ide pola MVVM didasarkan terutama pada lapisan View (pola Pengamat) mengamati perubahan data di lapisan ViewModel dan menanggapi perubahan melalui mekanisme pengikatan data.

Implementasi pola MVVM dapat dicapai dengan banyak cara. Namun, ada baiknya memasukkan mekanisme pengikatan data di dalamnya. Berkat ini, logika lapisan Tampilan diminimalkan, kode menjadi lebih teratur, dan pengujian menjadi lebih mudah.

Jika pola MVP berarti bahwa Presenter secara langsung memberi tahu View apa yang akan ditampilkan, MVVM ViewModel memaparkan aliran peristiwa yang dapat dikaitkan dengan Views. ViewModel tidak lagi perlu menyimpan referensi ke View seperti halnya dengan Presenter. Ini juga berarti bahwa semua antarmuka yang diperlukan oleh pola MVP sekarang tidak diperlukan.

Tampilan juga memberi tahu ViewModel tentang berbagai tindakan, seperti yang terlihat pada grafik di atas. Oleh karena itu, pola MVVM mendukung pengikatan data dua arah antara View dan ViewModel. View memiliki referensi ke ViewModel, tetapi ViewModel tidak memiliki informasi tentang View.

Keuntungan

1. Pengujian unit lebih mudah karena Anda tidak kecanduan View. Cukup untuk memverifikasi bahwa variabel yang dapat diamati diposisikan dengan benar saat Model berubah saat pengujian.
2. ViewModels bahkan lebih ramah untuk pengujian unit karena mereka hanya mengekspos status dan, oleh karena itu, dapat diuji secara independen tanpa menguji bagaimana data akan dikonsumsi. Singkatnya, tidak ada ketergantungan pada tampilan.
3. Hanya View yang berisi referensi ke ViewModel, bukan sebaliknya. Ini memecahkan masalah kopling ketat. Satu Tampilan dapat mereferensikan beberapa ViewModels.
4. Bahkan untuk Tampilan yang kompleks, kita dapat memiliki ViewModel yang berbeda dalam hierarki yang sama.

Kekurangan

1. Mengelola ViewModels dan statusnya di UI yang kompleks terkadang menantang bagi pemula.

Ringkasan

MVVM menggabungkan keunggulan yang disediakan oleh MVP saat menggunakan manfaat pengikatan data dan komunikasi berbasis peristiwa. Hasilnya adalah pola di mana Model mengontrol sebanyak mungkin operasi, dengan pemisahan kode dan kemampuan pengujian yang tinggi.

MVC vs MVP vs MVVM: Perbandingan

MVC vs MVP vs MVVM: Ringkasan

Baik pola MVP maupun pola MVVM secara signifikan lebih baik daripada pola MVC. Cara mana yang Anda pilih sangat tergantung pada preferensi Anda. Namun, saya harap artikel ini telah menunjukkan kepada Anda perbedaan utama di antara mereka dan akan membuat pilihan lebih mudah.

Mencari alternatif?

Pilih lintas platform!

Bibliografi:

1. Cervone, S. (2017) Model-View-Presenter: Pedoman Android.
2. Dang, AT (2020) MVC vs MVP vs MVVM.
3. Muntenescu, F. (2016) Pola Arsitektur Android Bagian 1: Model-View-Controller.
4. Muntenescu, F. (2016) Pola Arsitektur Android Bagian 2: Model-View-Presenter.
5. Muntenescu, F. (2016) Pola Arsitektur Android Bagian 3: Model-View-ViewModel.