В поисках идеальной архитектуры / Comments / Habr

iWheelBuy Dec 20 2017 at 16:01

Вы меня совершенно запутали в плане MVVM подхода!

Вы пишите:

Через какое-то время мы поняли, что одним MVVM не обойдемся. Класс view controller постепенно «распухал», особенно это было заметно, если на экране вызывается несколько запросов.

Я всегда думал, что ViewController (View) не вызывает запросы в MVVM подходе! Но в вашей интерпретации с запросами работает именно ViewController (View). Ведь это речь о запросах к сети / к базе?!

Далее вы пишите:

Следующим шагом выделили обращение к сервисам в отдельную сущность – presentation model и view controller перестал знать об их существовании.

Эти слова подтверждают, что с сервисами (в том числе сервис по работе с сетью) работает ViewController (View) в вашем MVVM подходе. Это точно не про MVC шла речь?

Чуть раньше в публикации вы ссылаетесь на вот эту статью, но в ней не описывается работа с сервисами. Зато в ней в самом низу есть ссылка на более подробную публикацию этого же автора:

you can check out this blog post explaining the benefits of MVVM in greater detail

В этом источнике вот что говорится о запросах к сети и их расположении:

...because network calls should be done asynchronously, so if a network request outlives the model that owns it, well, it gets complicated. You definitely should not put network code in the view, so that leaves… controllers. This is a bad idea, too, since it contributes to our Massive View Controller problem...

...view model is an excellent place to put validation logic for user input, presentation logic for the view, kick-offs of network requests, and other miscellaneous code...

Создается впечатление, что PresentationModel у вас очень уж похож на ViewModel (by Ash Furrow)… или нет?

Помогите мне найти правду и понять: кто в действительности в MVVM занимается работой с сервисами?

vani2 Dec 20 2017 at 16:37

У себя мы разделили:

View Model для View Controller (как у Ash Furrow) – назвали её Presentation Model. Она выполняет запросы к серверу и отвечает за создание View Model для View и ячеек.
View Model для отдельной ячейки, View – «глупые» объекты, которые знают только о том, как поля модели преобразовать для отображения пользователю. Никакие запросы View Model у нас не выполняет.

Отвечая на вопрос про каноничный MVVM – здесь я считаю, что нужно ориентироваться на Ash Furrow, в конце его книге «Functional Reactive Programming on iOS» разобран пример с вызовом запросов к серверу из View Model. Пример слегка устарел – Objective-C и ReactiveCocoa, но для понимания этого достаточно.