MVP vs MVC vs MVVM vs VIPER. Apa yang Lebih Baik Untuk Pengembangan iOS?

Sama seperti setiap rumah memiliki ruang bawah tanah yang kokoh, setiap proyek perangkat lunak, memiliki arsitektur perangkat lunak tempat ia dibangun, dan setiap proyek memiliki struktur aplikasinya sendiri. Jenis pola arsitektur dapat bervariasi, tetapi ada 4 yang paling umum digunakan - yang terus dikritik oleh seluruh dunia TI tetapi terus digunakan pada saat yang sama: MVC, MVP, MVVM dan Viper (yang terakhir sebagai pola arsitektur iOS kebanyakan) . Perbandingan pola-pola ini dan memilih yang lebih cocok untuk setiap kasus proyek yang ditulis oleh Swift akan ditemukan lebih lanjut dalam artikel ini.

Mengikuti urutan kronologis, setelah pola desain perangkat lunak pertama muncul, masalah umum dari pola arsitektur pengembangan ios itu tidak butuh waktu lama untuk tiba.

Misalnya, masalah komunikasi server-klien - bagaimana seseorang berinteraksi dengan yang lain? Atau yang berbeda - masalah memisahkan logika bisnis aplikasi dari logika dalam aplikasi; bagaimana kinerja yang satu ini dalam hal arsitektur aplikasi? Karena mereka berbagai pola desain untuk lapisan arsitektur yang berbeda telah melihat dunia; yang paling terkenal di antara mereka adalah:

- Pola desain tunggal.

Pola ini memungkinkan satu kelas untuk diterapkan ke satu objek saja, dan opsi ini digunakan ketika jumlah instans yang terbatas (atau hanya satu instans) disetujui oleh sistem.

- Pola desain dekorator.

Berbeda dengan singleton, pola ini, (atau disebut Wrapper bersama dengan pola Adaptor), memungkinkan perilaku tertentu ditambahkan ke satu objek (baik secara statis atau dinamis), dan semua ini tanpa memengaruhi perilaku objek lain ini satu berbagi kelas dengan.

- Pola desain jembatan.

Pertama kali diperkenalkan oleh Gang of Four yang terkenal - penulis buku "Design Patterns", pola arsitektur ini "menggunakan enkapsulasi, agregasi, dan dapat menggunakan pewarisan untuk memisahkan tanggung jawab ke dalam kelas yang berbeda. Ketika kelas sering muncul, fitur berorientasi objek pemrograman menjadi sangat berguna karena perubahan kode program dapat dilakukan dengan mudah dengan pengetahuan awal program yang minimal. [Sumber: Wiki]

Meskipun pola-pola itu sangat berbeda, masalah umum penulis kode telah terjadi pada masing-masing pola tersebut; misalnya, dengan "massivitas" Singleton. Singleton terlalu global, karena dependensi kode Anda tersembunyi jauh di dalam aplikasi Anda, bukannya diekspos di antarmuka. Itulah sebabnya selama proses pengembangan perangkat lunak, pola-pola baru terus-menerus muncul.

4 pola yang paling umum digunakan adalah MVC, MVP, MVVM dan VIPER (terutama untuk iOS).

Dikembangkan dalam urutan yang sama seperti yang tercantum, semuanya memiliki kelebihan dan kekurangannya sendiri, menyebabkan banyak perselisihan tentang di mana harus menerapkan masing-masing. Memberi sedikit lebih banyak perhatian pada praktik terbaik yang mereka terapkan mungkin akan sedikit memperjelas.

pola MVC

Kakek dari semua pola perangkat lunak, pertama kali diperkenalkan pada awal 1970-an oleh ilmuwan komputer Norwegia Trygve Reenskaug, Module - View - Controller, yang dikenal luas sebagai MVC, adalah salah satu pendekatan pola pertama dari Pemrograman Berorientasi Objek.

Bagian Tampilan bertanggung jawab untuk menampilkan segala sesuatu untuk pengguna sistem (antarmuka aplikasi seluler atau web, dll.). Model umumnya bertanggung jawab atas database, entitas bisnis, dan data lainnya. Pada gilirannya, Controller mengatur kerja Model, data yang diberikan ke database, ditampilkan dari database tersebut ke bagian View dan sebaliknya.

Betapapun universalnya model MVC, dua pesaing terbesar - Apple dan Google memiliki pola mereka sendiri yang mewakili Sistem Model - Tampilan - Pengendali. Masalah sistem Apple terletak pada hubungan yang erat antara bagian View dan Controller, ketat hampir sampai menyatukan View & Controller, dan membiarkan bagian Model terpisah.

Akibatnya, ini menghasilkan proses pengujian yang buruk - hanya Model yang dapat diperiksa, V&C (karena koneksi yang ketat) tidak dapat diuji sama sekali.

Koneksi kuat antara segmen Controller dan View terbukti benar-benar “tidak sehat” dalam hal perangkat lunak, sehingga pola baru segera muncul di dunia.

pola MVP.

Banyak dari kita telah mendengar pintasan ini dalam konteks Produk yang Layak Minimum, tetapi dalam hal rekayasa perangkat lunak itu berarti sesuatu yang berbeda. Pola Model View Presenter memiliki beberapa poin kunci, membentuk jurang yang lebar antara pola tersebut dan MVC:

Model MVP

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

• Lebih mudah untuk menguji unit karena interaksi dengan tampilan melalui antarmuka.

• Biasanya View to Presenter = memetakan satu-ke-satu. Tampilan kompleks mungkin memiliki multi penyaji.

Pola MVC

• Pengontrol didasarkan pada perilaku dan dapat dibagikan di seluruh tampilan

• Dapat bertanggung jawab untuk menentukan tampilan mana yang akan ditampilkan
  [Sumber: Infragistics]

Dalam pengaturan ini, fungsi Model tetap sama; Presenter bertanggung jawab atas logika bisnis masing-masing. Bagian V adalah salah satu yang menarik - karena dibagi menjadi dua bagian View dan View Controller, yang berwenang untuk interaksi. Ketika ada pertanyaan MVVM vs MVC, sistem jenis ini memecahkan masalah mode Tampilan dan Pengontrol "kecanduan berat" yang digunakan dalam pola MVC.

Hambatan pengujian juga diselesaikan dalam hal ini, sebagai Model, Tampilan dengan interaksi pengguna, dan bagian Presenter - semua ini dapat diuji.
Ketidaknyamanan yang ada ada di bagian Presenter - namun terlalu besar, namun memperhitungkan semua logika bisnis yang ada. Itulah sebabnya tindakan selanjutnya ikut bermain, bernama ...

pola MVVM

Pola arsitektur perangkat lunak Model-View-ViewModel telah dibuat pada tahun 2005 oleh John Gossman, salah satu arsitek Microsoft. Tiga komponen inti dari model MVVM masing-masing adalah:
Model adalah “sebuah implementasi dari model domain aplikasi yang mencakup model data bersama dengan logika bisnis dan validasi. Contoh objek model termasuk repositori, objek bisnis, objek transfer data (DTO), Objek CLR Lama Biasa (POCO), dan objek entitas dan proxy yang dihasilkan. [Sumber: Microsoft]

Sekali lagi, tampilan adalah segala sesuatu yang dapat dilihat pengguna - tata letak, struktur, dan tampilan segala sesuatu di layar. Pada dasarnya, di dalam aplikasi itu akan menjadi halaman aplikasi. View mendapatkan dan mengirim pembaruan hanya ke ViewModel, tidak termasuk semua komunikasi antara bagian ini dan Model itu sendiri.

ViewModel seharusnya menjadi "rantai interkoneksi" antara komponen sistem View dan Model, dan fungsi utamanya adalah untuk menangani logika View. Biasanya, model tampilan berinteraksi dengan model dengan memanggil metode di kelas model. Model tampilan kemudian menyediakan data dari model dalam bentuk yang dapat digunakan dengan mudah oleh tampilan, seperti yang dinyatakan Microsoft.

Perbedaan utama antara MVC dan iOS MVVM adalah bahwa pola distribusi MVVM lebih baik daripada di MVC yang terdaftar sebelumnya, tetapi jika dibandingkan dengan MVP, itu juga kelebihan beban secara besar-besaran. Pengujian adalah masalah yang sangat penting di sini, karena saat menulis kode dengan jelas, Anda tidak dapat menjamin bahwa seluruh proyek akan berfungsi dengan baik - pengujian, dengan catatan, membantu memastikannya.

Evolusi pola arsitektur berikutnya baru-baru ini dirilis dan sekarang merupakan pendekatan arsitektur perangkat lunak terbaru.

Arsitektur iOS VIPER

Mencari solusi arsitektur terbaik untuk disampaikan, pengembang iOS di seluruh dunia bertemu dengan apa yang disebut pendekatan "Arsitektur Bersih", yang diperkenalkan oleh Paman Bob pada Clean Coders - platform terkenal yang menyediakan sesi pelatihan untuk para profesional perangkat lunak di seluruh dunia.

Arsitektur Bersih membagi struktur logis aplikasi menjadi beberapa tingkat tanggung jawab. Pada gilirannya, "pemisahan" ini menyelesaikan masalah ketergantungan yang ketat dan meningkatkan ketersediaan pengujian di semua level.

VIPER untuk pengembangan ios

VIPER adalah realisasi Arsitektur Bersih untuk aplikasi yang dibangun di iOS. Sebagai aturan umum untuk semua nama pola, ini juga merupakan backronym, untuk View, Interactor, Presenter, Entity, dan Routing. Setiap bagian VIPER bertanggung jawab atas elemen tertentu, terutama:

1. Tampilan bertanggung jawab untuk mencerminkan tindakan yang dibuat pengguna dengan antarmuka

2. Tanggung jawab penyaji dalam pola VIPER cukup terbatas - ia menerima pembaruan dari Entitas, tetapi tidak mengirim data apa pun ke sana;

3. Interactor adalah bagian sistem yang sebenarnya berhubungan dengan Entitas. Skema ini bekerja dalam arah berikut: Presenter menginformasikan Interactor tentang perubahan dalam model View, kemudian Interactor menghubungi bagian Entity, dan, dengan data yang diterima dari Entity Interactor akan kembali ke Presenter, yang memerintahkan View untuk mencerminkannya bagi pengguna. Semua model data, semua entitas, dan semua situs web terhubung ke bagian Interactor.

4. Entitas terdiri dari objek yang dikendalikan oleh Interactor (judul, konten, dll.)Entitas tidak pernah berinteraksi dengan Presenter secara langsung, hanya melalui I-part.

5. Perutean (atau Wireframe seperti yang kadang-kadang disebut) bertanggung jawab untuk navigasi antara semua layar, dan, pada dasarnya, untuk perutean. Wireframe mengontrol objek UIWindow, UINavigationController dan sebagainya.

Khususnya dalam sistem arsitektur iOS, semuanya dibangun di atas kerangka kerja yang disebut UIkit, yang mencakup semua komponen Apple MVC, tetapi tanpa koneksi ketat yang digunakan untuk membuat pembuat kode gila sebelumnya.

Modul VIPER juga bermanfaat dalam hal pengujian unit, karena distribusi pola yang hebat memungkinkan Anda menguji semua fungsi yang tersedia. Dalam banyak hal, ini adalah kesulitan utama yang dihadapi pengembang dengan pola perangkat lunak MVC, MVP, dan MVVM sebelumnya.

Untuk Mahkota itu Semua.

Semua 4 pola desain perangkat lunak ini sering disebut sebagai salah satu Pola arsitektur terbaik untuk pengembangan iOS, meskipun semuanya kurang ideal dan jelas tidak digunakan secara universal untuk setiap proyek yang Anda kembangkan. Di sisi suram, berikut adalah daftar singkat masalah yang dimiliki setiap pola:

• MVC, MVP, MVVM - semuanya memiliki masalah "koneksi ketat" ini, yang membuat memperkenalkan pembaruan ke pengembangan, dan mengujinya setelah itu cukup sulit untuk diselesaikan.

• VIPER vs MVVM, MVC atau MVP , dianggap sebagai kasus yang menang; meskipun meskipun fleksibilitasnya tinggi dan kemampuan uji yang hebat juga memiliki banyak nuansa yang sulit untuk dihasilkan.

Apakah ada solusi yang 100% solid? Tidak juga, tetapi untuk setiap proyek Anda, salah satu dari 4 pola aplikasi iOS ini mungkin yang Anda butuhkan. Dan jika tidak, maka campuran keduanya akan menjadi. Atau bahkan mungkin tiga. Keberuntungan dikatakan menyukai yang berani, jadi mengapa Anda tidak bermain dengan pola desain perangkat lunak dengan berani?

Ditulis oleh Max Mashkov dan Elina Bessarabova.