Pull to refresh

Comments 7

Странно, что не сделали последний шаг оптимизации SVIP - исключение Worker.

Cкорее VIPER и RIBs похожи. У (S)VIP принципиальное отличие - одностороння связь между View Interactor и Presenter

У дядюшки Боба в его чистой архитектуре присутствует контроллер. Поглядите хотя бы на ту картинку, которую Вы привели в своей статье. В ее правом нижнем углу имеется контроллер. А вот куда контроллер делся в VIP, который якобы является реализацией чистой архитектуры с этой картинки? И почему Вы продолжаете с этой же ошибкой в Вашей архитектуре?

У Мартина контроллер приведен для примера как сущность за пределами вариантов использования. Не следует связывать контроллер с картинки Мартина с какой-то конкретной сущностью в iOS. С точки зрения Мартина контроллер это то что формирует запросы в интерактор. То есть, у нас это Вид.

Не соглашусь с тем, что он приведен "чисто для примера". Но соглашусь с тем, что он "формирует запросы в интерактор".

Контроллер у дядюшки Боба (да и не только у него, это часто встречающаяся практика) осуществляет ту же функцию, что и презентер, только в обратную сторону. Контроллер и презентер у дяди Боба – это прослойка между двумя независимыми слоями, разделенная по направлению преобразования на независимые сущности. Просто гляньте где у него в кольце контроллер, а где презентер. Контроллер обычно работает с вводом пользователя, а презентер – наоборот – с выводом ему информации. Это реализация принципа инверсии зависимостей, порт-адаптер (преобразование) и единой ответственности (направление). Не зря на картинке и то, и другое отображено одинаково, только с разным направлением управляющего сигнала.

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

Не утверждаю, что это неверно и неправильно.

Просто, похоже, что VIP – это не "чистая архитектура" от дяди Боба. В чистой архитектуре вот к той сноске в правом нижнем углу нужно просто слева подрисовать представление ("Вид") и замкнуть граф в кольцо.

Вы не считаете это ошибкой реализации VIP относительно описанных у дяди Боба колец с адаптерами?

"Без такого адаптера "Вид" в VIP будет все знать о бизнес-логике".

Не всё. Вид является источником команд для интерактора. Он осуществляет управляющие воздействия на интерактор, ничего не зная о том, как интерактор будет реагировать на управляющие воздействия.

Просто, похоже, что VIP – это не "чистая архитектура" от дяди Боба.

Сама концепция чистой архитектуры от Мартина, помимо чистых компонент, подразумевает неизбежное присутствие и грязных. В архитектурном шаблоне SVIP чистым является интерактор. Именно на изоляцию бизнес-логики в интеракторе, и его тестируемость (и только его) были направлены усилия при создании шаблона SVIP. Презентер и вид не являются чистыми компонентами. Обоснование этого решения развернуто изложено в статье.

Вы не считаете это ошибкой реализации VIP относительно описанных у дяди Боба колец с адаптерами?

Не считаю. Само наличие концентрических колец в схеме Мартина указывает с одной стороны направление зависимостей, а с другой на ослабление чистоты уровней от центра вовне.

Sign up to leave a comment.