Comments 5
очень и очень спорно.
Получается, что UIViewController просто проксирует модельки между презентером и UIView? тогда зачем он нужен? может UIViewController и сделать реализующим функции презентера?
Далее — у нас есть Interactor и workers, скажем — у меня несколько workerов общих, которые используются в interactor, а interactor не имеет другой логики — он опять что-то проксирует, тогда зачем он нужен?
А если использовать те же сервисы, то слоев проксирования возрастает кратно.
По итогу — получаем ту же модель MVC, только C — контроллер размазан по максимальному количеству слоев выполняющим все все функции, M — модель в виде глупых структур данных (пассивная модель), ну и хотя бы V — View без логики внутри.
Clean xyz — обычно происходит из книг статей Дядюшки Боба, но он не про такие слои писал… совсем не про это
Получается, что UIViewController просто проксирует модельки между презентером и UIView? тогда зачем он нужен? может UIViewController и сделать реализующим функции презентера?
Далее — у нас есть Interactor и workers, скажем — у меня несколько workerов общих, которые используются в interactor, а interactor не имеет другой логики — он опять что-то проксирует, тогда зачем он нужен?
А если использовать те же сервисы, то слоев проксирования возрастает кратно.
По итогу — получаем ту же модель MVC, только C — контроллер размазан по максимальному количеству слоев выполняющим все все функции, M — модель в виде глупых структур данных (пассивная модель), ну и хотя бы V — View без логики внутри.
Clean xyz — обычно происходит из книг статей Дядюшки Боба, но он не про такие слои писал… совсем не про это
Согласен, что не стоит создавать классы ради классов.
Я в первый раз использовал CleanSwift-шаблон год назад, и пришел к выводу, что он мне в чистом виде не подходит. Переделал шаблон под свое видение и не столь категоричен в плане «Одна сцена — один экран приложения», например, что-то типа «Мастер регистрации», который состоит из нескольких экранов, представлен одним VIP-циклом, дочерние формы (шаги мастера) — это лишь часть бОльшего View.
С другой стороны, этот архитектурный подход очень хорошо демонстрирует и реализует популярный сейчас принцип DDD (Domain Driven Development).
В целом, мне нравится описанный архитектурный подход к написанию приложений на Swift под iOS, в купе с ServiceLocator и Storyboard-per-Scene (VIP-cycle)
Я в первый раз использовал CleanSwift-шаблон год назад, и пришел к выводу, что он мне в чистом виде не подходит. Переделал шаблон под свое видение и не столь категоричен в плане «Одна сцена — один экран приложения», например, что-то типа «Мастер регистрации», который состоит из нескольких экранов, представлен одним VIP-циклом, дочерние формы (шаги мастера) — это лишь часть бОльшего View.
С другой стороны, этот архитектурный подход очень хорошо демонстрирует и реализует популярный сейчас принцип DDD (Domain Driven Development).
В целом, мне нравится описанный архитектурный подход к написанию приложений на Swift под iOS, в купе с ServiceLocator и Storyboard-per-Scene (VIP-cycle)
Очень Интересный пример архитектуры :-)
Только думаю что однонаправленность работы слоев не всегда будет оптимальным решением, и попробую пояснить свою позицию:
Если presenter отвечает за преобразование данных во viewmodel, а interactor — за получение данных откуда либо, то любая прочая логика снова будет нагружать только ViewController, либо здесь не хватает четвертого слоя. Например логика с Router-ом, или с сервисами
Тоже считаю что спорно, и с некоторыми особенностями сложных проектов может не справиться
Только думаю что однонаправленность работы слоев не всегда будет оптимальным решением, и попробую пояснить свою позицию:
Если presenter отвечает за преобразование данных во viewmodel, а interactor — за получение данных откуда либо, то любая прочая логика снова будет нагружать только ViewController, либо здесь не хватает четвертого слоя. Например логика с Router-ом, или с сервисами
Тоже считаю что спорно, и с некоторыми особенностями сложных проектов может не справиться
Спасибо за комментарий! По сути ViewController остается максимально «тупым», вся логика переходов и передачи данных выносится в Router (я постарался подробно это описать в следующей статье). Сам ViewController только и умеет, что брать данные и отправлять их в Interactor на обработку (помимо получения/обновления данных View).
Конечно, в крупных проектах все сильно разрастется на любой архитектуре. Для этого сцены можно (даже нужно) бить на контейнеры. По крайней мере в данный момент с разрастанием не сталкивался, но дальше будет видно :)
Конечно, в крупных проектах все сильно разрастется на любой архитектуре. Для этого сцены можно (даже нужно) бить на контейнеры. По крайней мере в данный момент с разрастанием не сталкивался, но дальше будет видно :)
UFO just landed and posted this here
Sign up to leave a comment.
Общее представление об архитектуре Clean Swift