Baru-baru ini saya memutuskan untuk mulai belajar Pengembangan iOS, dan sampai saat ini saya telah membaca Pemrograman iOS: Panduan Peternakan Besar Nerd . Dalam buku ini penulis menggambarkan pola desain MVCS - Model-View-Controller-Store , ide dasarnya adalah bahwa karena banyak aplikasi menggunakan berbagai sumber data eksternal, menjaga logika permintaan dalam pengontrol dapat menjadi sangat berantakan, sebaliknya penulis mengusulkan bahwa memindahkan semua logika permintaan dari controller dan ke objek yang terpisah.
Singkatnya mengutip buku
Model-View-Controller-Store menempatkan logika permintaan ke objek yang terpisah, dan kami menyebut objek ini toko (Gambar 28.4). Menggunakan objek toko meminimalkan kode redundan dan menyederhanakan kode yang mengambil dan menyimpan data. Yang paling penting, ini memindahkan logika untuk berurusan dengan sumber eksternal ke dalam kelas yang rapi dengan tujuan yang jelas dan fokus. Ini membuat kode lebih mudah dipahami, yang membuatnya lebih mudah untuk dipelihara dan di-debug, serta berbagi dengan programmer lain di tim Anda.
Dan
Yang keren tentang toko asinkron adalah meskipun banyak objek melakukan banyak pekerjaan untuk memproses permintaan, aliran permintaan dan responsnya ada di satu tempat di controller. Ini memberi kita manfaat kode yang mudah dibaca dan juga mudah dimodifikasi.
Saya ingin mengetahui lebih lanjut tentang pola ini dan untuk melihat apa yang mungkin orang lain katakan tentang hal itu, tetapi ketika mencari online satu-satunya referensi yang dapat saya temukan adalah untuk buku yang sama (apakah pola itu mungkin dikenal dengan nama lain?).
Bagi saya logika penulis tampaknya masuk akal, dan sepertinya perpanjangan logis dari pola MVC biasa, tetapi mungkin itu karena saya tidak benar-benar memiliki banyak pengalaman dengan pola MVC dalam praktiknya (selain dari terjun ke dalam pengembangan iOS yang saya miliki semacam MVV yang digunakan dengan backbone.js (yaitu, jika Anda menganggapnya MVC )).
Saya berharap bahwa mungkin seseorang dengan pengalaman lebih banyak dapat menjelaskan apakah ada kelemahan / masalah yang jelas dengan pola MVCS yang saya lewatkan.
sumber
Jawaban:
"Store", dalam hal pola desain MVCS, cenderung condong ke arah logika penyimpanan. Dalam kasus iOS, ini biasanya merupakan implementasi Data Inti. Jika Anda membuat templat yang didukung Data Inti di Xcode, Anda akan melihat aspek "Store" dari pola desain ini yang tersimpan di kelas AppDelegate.
Untuk membawa ini ke tingkat berikutnya, saya akan sering membuat kelas manajer tunggal yang menangani pengaturan tumpukan Data Core, dan berurusan dengan semua pengambilan / penghematan yang terlibat dengan tumpukan. Seperti kata kutipan yang Anda sebutkan, ini membuatnya sangat mudah untuk tidak hanya memanggil metode-metode itu, tetapi untuk menyesuaikannya jika diperlukan, sebagai lawan dari menyimpan / mengambil panggilan di semua tempat di pengontrol tampilan yang berbeda.
Paradigma "Store" tidak terbatas pada Core Data. Toko Anda mungkin hanya layanan web. Mungkin Anda memiliki kelas yang berinteraksi dengan Facebook, Twitter, Yelp, atau API berbasis REST lainnya. Saya telah menemukan (dan juga mengikuti tren) bahwa kelas-kelas semacam ini juga bernama Manajer. Mereka benar-benar mengelola semua detail internal sehingga kelas-kelas Anda yang lain hanya bisa memasukkan atau mengeluarkan apa yang mereka butuhkan.
Sejauh yang jelas cacat atau masalah dengan pola desain ini ... Seperti halnya pola desain apa pun, masalah yang paling mencolok adalah memastikan bahwa Anda telah mengatur proyek Anda sedemikian rupa sehingga sesuai dengan paradigma. Terutama dengan pola desain yang baru bagi Anda, ini kadang-kadang bisa menjadi bagian tersulit. Manfaat memecah logika "Store" Anda ke dalam kelasnya sendiri adalah fakta bahwa itu membuat perawatan kode lebih mudah.
sumber
'Store' dalam konteks ini sangat mirip dengan Repositori atau Layanan . Dalam hal ini, ini adalah pola yang sangat umum. Kelemahan / masalah akan bervariasi dengan implementasi Anda dan domain masalah.
Pada tingkat umum, sepertinya buku menggunakan 'Store' untuk mewakili tingkat logika bisnis + tingkat logika pengambilan data yang menangani sekumpulan data yang mungkin atau mungkin tidak menjadi bagian dari aplikasi Anda.
Misalnya, membungkus api twitter di 'Toko' adalah cara yang bagus untuk memecah logika itu.
Setelah dipikirkan lebih lanjut
Menggunakan definisi MVC ini (yang menurut saya cukup tepat), 'Store' sebenarnya adalah bagian dari model. Penggambaran antara apakah ini merupakan ekstensi ke MVC atau apakah itu merupakan pola pengambilan data tidak terlalu berguna. Mereka akhirnya tampak seperti kode yang sama.
Intinya, saya pikir Anda akan baik-baik saja mengikuti saran yang mereka sarankan (tampaknya keseluruhan suara).
sumber