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