MVCS - магазин контролерів перегляду моделей

Нещодавно я вирішив почати вивчати розробку iOS, і для цього я читав програмування iOS: Посібник із ранчо Великого Нерда . У книзі автори описують модель дизайну MVCS - Model-View-Controller-Store , основна ідея полягає в тому, що оскільки багато додатків використовують безліч зовнішніх джерел даних, що зберігають логіку запиту в контролері, вони можуть стати дуже безладним, замість цього автори запропонуйте перемістити всю логіку запиту з контролера та перенести в окремий об'єкт.

Коротше кажучи, щоб процитувати книгу

Model-View-Controller-Store розміщує логіку запиту в окремому об'єкті, і ми називаємо цей об’єкт магазином (мал. 28.4). Використання об’єкта магазину мінімізує зайвий код та спрощує код, який отримує та зберігає дані. Найголовніше - це переміщення логіки поводження з зовнішнім джерелом в охайний клас з чіткою і зосередженою метою. Це полегшує розуміння коду, що полегшує підтримку та налагодження, а також ділитися з іншими програмістами у вашій команді.

І

Класна річ у асинхронних магазинах полягає в тому, що, хоча багато об’єктів роблять багато роботи для обробки запиту, потік запиту та його відповідь знаходяться в одному місці в контролері. Це дає нам перевагу коду, який легко читати, а також легко змінювати.

Я хотів дізнатися більше про цю закономірність і побачити, що можуть сказати про неї інші, але під час пошуку в Інтернеті єдині згадки, які я міг знайти, були саме на ту саму книгу (чи може бути відомий зразок якогось іншого імені?).

Мені авторська логіка, здається, має сенс, і це здається логічним розширенням звичайного шаблону MVC, але, можливо, це тому, що я не маю особливого досвіду роботи з шаблоном MVC на практиці (окрім набігу на розробку iOS у мене є різновид використовуваного MVV з backbone.js (тобто якщо ви вважаєте його MVC )).

Я сподівався, що, можливо, хтось із більшим досвідом може пролити деяке світло на те, чи є якісь явні недоліки / проблеми з моделлю MVCS, який мені не вистачає.

"Магазин", у випадку моделей дизайну MVCS, як правило, схиляється до логіки зберігання. У випадку з iOS, це звичайно реалізація основних даних. Якщо ви створите шаблон, захищений основними даними, у Xcode, ви побачите аспект «Зберегти» цього шаблону дизайну, захований у класі AppDelegate.

Щоб підняти це на наступний рівень, я часто буду створювати одиночний клас менеджера, який обробляє налаштування стека Core Data, і займається всім вилученням / збереженням, пов'язаним зі стеком. Як говориться в цитаті, про яку ви згадали, це дозволяє дуже просто не тільки викликати ці методи, але і коригувати їх у разі потреби, на відміну від збереження / отримання викликів в усьому місці в різних контролерах перегляду.

Парадигма "Магазин" не обмежується основними даними. У вашому магазині може бути просто веб-служба. Можливо, у вас є клас, який взаємодіє з Facebook, Twitter, Yelp або іншим API на базі REST. Я виявив (і подібним чином слідую за тенденцією), що такі класи також мають ім'я менеджер. Вони дуже буквально керують усіма внутрішніми деталями, щоб ваші інші класи могли просто вкласти або вийти саме те, що їм потрібно.

Що стосується очевидних недоліків або проблем із цією схемою дизайну ... Як і у випадку з будь-якою схемою дизайну, найяскравішою проблемою є те, що ви налаштували свій проект таким чином, щоб ви стикалися з парадигмою. Особливо з новим для вас візерунком дизайну, це іноді може бути найскладнішою частиною. Перевага розбиття логіки "Store" на власний клас полягає в тому, що це значно спрощує технічне обслуговування коду.

"Зберігати" в цьому контексті дуже схоже на сховище або сервіс . У цьому випадку це надзвичайно поширена закономірність. Недоліки / проблеми залежать від вашої реалізації та проблемної області.

На загальному рівні схоже, що книга використовує "Магазин", щоб представити рівень бізнес-логіки + рівень логіки пошуку даних, який обробляє набір даних, які можуть бути або не бути частиною вашої програми.

Наприклад, обгортання api Twitter у "Магазині" - хороший спосіб розділити цю логіку.

Після подальшої думки
Використовуючи це визначення MVC (яке, на мою думку, досить непомітне), "Магазин" - це дійсно підмножина моделі. Розмежування того, чи це розширення на MVC, чи це шаблон пошуку даних, не дуже корисний. Вони в кінцевому підсумку виглядають як той самий код.

Підсумок, я думаю, ви будете добре виконувати поради, які вони пропонують (здається, загалом це звучить).