MVCS - магазин контроллеров модельного представления

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

Короче процитировать книгу

Model-View-Controller-Store помещает логику запроса в отдельный объект, и мы называем этот объект хранилищем (рисунок 28.4). Использование объекта хранилища минимизирует избыточный код и упрощает код, который выбирает и сохраняет данные. Наиболее важно, что это перемещает логику для работы с внешним источником в аккуратный класс с ясной и сфокусированной целью. Это облегчает понимание кода, облегчает поддержку и отладку, а также позволяет делиться с другими программистами в вашей команде.

А также

Крутая вещь в асинхронных хранилищах состоит в том, что, хотя многие объекты выполняют большую работу для обработки запроса, поток запроса и его ответ находятся в одном месте в контроллере. Это дает нам преимущество кода, который легко читать, а также легко модифицировать.

Я хотел узнать больше об этом шаблоне и узнать, что другие могут сказать об этом, но при поиске в Интернете единственные ссылки, которые я мог найти, были на эту же книгу (возможно, шаблон известен под другим именем?).

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

Я надеялся, что, возможно, кто-то с большим опытом сможет пролить свет на то, есть ли какие-то очевидные недостатки / проблемы с шаблоном MVCS , которые я пропускаю.

«Store» в случае шаблонов проектирования MVCS имеет тенденцию склоняться к логике хранения. В случае с iOS это обычно реализация Core Data. Если вы создадите базовый шаблон с поддержкой данных в XCode, вы увидите аспект «Store» этого шаблона проектирования, спрятанный в классе AppDelegate.

Чтобы перейти на следующий уровень, я часто создаю класс синглтон-менеджера, который обрабатывает настройку стека базовых данных и занимается всеми операциями извлечения / сохранения, связанными со стеком. Как сказано в приведенной вами цитате, это позволяет очень просто не только вызывать эти методы, но и настраивать их при необходимости, в отличие от необходимости сохранять / извлекать вызовы повсеместно в разных контроллерах представления.

Парадигма «Store» не ограничивается Core Data. Ваш магазин может быть просто веб-сервисом. Возможно, у вас есть класс, который взаимодействует с Facebook, Twitter, Yelp или другим API на основе REST. Я обнаружил (и точно так же следую за тенденцией), что эти виды классов также называются Менеджером. Они буквально управляют всеми внутренними деталями, так что ваши другие классы могут просто вставить или получить именно то, что им нужно.

Что касается очевидных недостатков или проблем с этим шаблоном проектирования ... Как и в случае с любым шаблоном проектирования, наиболее очевидной проблемой является обеспечение того, что вы настроили свой проект так, чтобы он сочетался с парадигмой. Особенно с новым для вас шаблоном дизайна, иногда это может быть самой сложной частью. Преимущество разделения вашей логики «Store» на собственный класс заключается в том, что она значительно упрощает поддержку кода.

«Хранить» в этом контексте очень похоже на хранилище или службу . В этом случае это чрезвычайно распространенная модель. Недостатки / проблемы будут зависеть от вашей реализации и проблемной области.

На общем уровне кажется, что книга использует «Store» для представления уровня бизнес-логики + уровень логики извлечения данных, который обрабатывает набор данных, которые могут быть или не быть частью вашего приложения.

Например, обертывание твиттер-API в «Store» - хороший способ отделить эту логику.

После дальнейших размышлений
Используя это определение MVC (которое я считаю весьма подходящим), «Магазин» действительно является подмножеством модели. Разграничение между тем, является ли это расширением MVC или шаблоном извлечения данных, не очень полезно. В итоге они выглядят как один и тот же код.

В итоге, я думаю, что вы будете в порядке, следуя советам, которые они предлагают (кажется, звучит в целом).