У меня немного вопросов к докладу Сергея:
1. Почему не стали использовать VIPER? Из-за любви к MVVM и реактиву?
2. Могут ли переиспользоваться фасады? Или что вы делаете, если в нескольких фасадах есть общая логика? Или фасады не относятся к определенному модулю?
3. Как фасад определяет, к какому адаптеру обращаться? Он хранит какое-то состояние?
4. Тестируете ли вы инъекции?
5. Почему между VM и View связь через делегирование?
6. Какой объект в вашей архитектуре отвечает за навигацию?
7. Если UI одного экрана сложный, разбиваете ли вы его на сабмодули? Если да, то как?
8. Что вы используете для работы с таблицами?
9. Примеры в презентации были написаны на Objective-C. Используете ли вы эту архитектуру в Swift проекте? Если да, то как собираете модули?
1. Когда мы начали менять нашу архитектуру, мы смотрели на VIPER, но некоторые аспекты нам показались лишними. Наличие небольшого опыта с MVVM, который хорошо ложился с использованием в связке с ReactiveCocoa, определил направление.
2. Все фасады наследуются от корневого, который содержит общую логику. Фасады разделены по принципу сущностей данных, которые он может получать, например — фасад резюме, фасад вакансий и т.д.
3. Аналогично разделению фасадов, адаптеры делятся образом и соответственно фасад резюме будет запрашивать данные у адаптера резюме.
4. Нет, инъекции мы не тестируем, упор был больше на бизнес-логику.
5. На самом деле можно было так же использовать сигналы как и на предыдущих слоях.
6. Тут я возможно немного слукавил, когда говорил, про принцип единственной ответственности. ViewModel c помощью делегата передает на слой View информацию о навигации, то есть ViewModel выполняет чуточку больше :) есть желание избавить ее от этой ответственности.
7. Все несколько проще, для данного случая мы выносим в категории модуля логику.
8. Немного не понял вопрос, можешь уточнить?
9. Что касается приложения на swift (производственный календарь), оно по своей структуре простое и оно написано в MVC.
  • По 3 вопросу — а если фасад использует несколько адаптеров, как он понимает, к какому обращаться?, к какому обращаться?
  • По 8 вопросу — я увидел на слайдах кастомные протокол для секции таблицы. Используете ли вы какое-то стороннее или свое решение для таблиц, чтобы избежать огромных свичей и if-else конструкций и методах delegate/datasource таблицы?
3. Если вернуться к примеру с авторизованным/неавторизованным пользователем, то фасад вакансий, на основе данных из фасада профиля, узнает статус пользователя и дальше if/else выбор адаптеров. Решили не усложнять данный момент механизмами состояний, и в то же время решение не мешает тестируемости кода.
8. Тут ты подметил абсолютно точно на тему switch, в некоторых местах громоздо выглядит, пока не нашли решения. Сталкивался ли ты с подобным и как решал?

Насчет таблиц — мы используем самочинную библиотеку TableViewTools, она отлично решает эту задачу. Если кратко — каждой ячейке соответствует определенный объект, который знает, как отрисовать ячейку, заполнить данными и отреагировать на actions. И почти вся логика работы с таблицей выносится из контроллера.

Спасибо за совет, изучим :)
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.