Сущности VIPER и где их хранить

Итак, в настоящее время я рефакторинг действительно большого проекта для архитектуры VIPER, и большинство представлений его модулей являются UITableViews. Я нашел почти все темы в Интернете о VIPER и UITableView, но одно остается неясным: где я должен хранить ViewModel и действительно ли они мне нужны?

Например, у меня есть простой модуль VIPER с UITableViewController, и мне нужно представить список элементов. Interactor извлекает JSON с массивом некоторых элементов, которые я декодирую в структуры Codable. Затем я передаю массив этих структур из интерактора обратно в презентатор по протоколу InteractorOutput. А теперь у меня два вопроса:

  1. Должен ли я использовать другую модель данных (ViewModel) для отображения данных в представлении, или я могу использовать уже существующую Codable Struct?

  2. Где я должен хранить свои ViewModels? Внутри Presenter запросите данные из представления следующим образом: Presenter.getData(forItemAt: indexPath.row). Или мне нужно подтолкнуть массив ViewModels к просмотру и попросить View показать их?


ios swift viewmodel clean-architecture viper-architecture
person S.Vlad    schedule 26.08.2020    source источник
comment
ИМО, я бы использовал ViewModel, а не Codable Struct. Codable можно передать в Presenter для преобразования в ViewModel, затем из View вы спросите Presenter.   -  person Duy Nguyen    schedule 26.08.2020

Ответы (1)


arrow_upward
0
arrow_downward

Как описано в https://TheSwiftDev.com/the-ultimate-viper-architecture-tutorial. ,

  • UITableView помещен в карантин в зоне просмотра.
  • Моделей представления как таковых нет. Эта цель других архитектур разделена в VIPER по-другому, в основном в зоне докладчика, но без явного знания самого представления (вместо того, чтобы сосредоточиться на бизнес-правилах варианта использования). Представление пользовательского интерфейса в зоне просмотра VIPER соответствует как минимум одному варианту использования. Данные, проходящие из зоны взаимодействия (сбор/хранение) через зону презентатора (применение правил/обработка правил бизнес-домена/приложения) в зону просмотра (и наоборот), моделируются без прямого знания конкретных конструкций пользовательского интерфейса конкретной ОС и их потребностей в параметрах. . При пересечении зон VIPER объекты моделируются как переносимые (даже если еще не переносимые) в другие пользовательские интерфейсы в других ОС. Например, при разработке приложений для iOS/iPadOS/WatchOS межзональный обмен событиями и данными/сущностями выполняется так, чтобы они как минимум не учитывали особенности конструкций и параметров представления пользовательского интерфейса iOS/iPadOS/WatchOS, чтобы 4 Зоны VIPER, отличные от просмотра и маршрутизатора {interactor, Presenter, Entities}, остаются неизменными в версии того же приложения для MacOS. С осторожностью (например, Swift на всех платформах, отличных от Apple; платформа OpenCombine вместо платформы Apple Combine для межзонального потока данных, реагирующего на эффекты) эту концепцию можно экстраполировать и на версию приложения для Android и UWP, но ориентированные на Apple части Зона взаимодействия также должна измениться, что является причиной помещения в карантин каждой темы, разделенной на части в зоне, чтобы она не заражала другие зоны (как видно из архитектуры Massive View Controller).
  • Зона докладчика вообще не должна знать или иметь доступ к конструкциям UITableView. Следовательно, Presenter.getData(forItemAt: indexPath.row) будет заменен докладчиком, работающим над набором сущностей, где набор сущностей может отображаться в пользовательском интерфейсе в зоне просмотра как UITableView на iOS/iPadOS/WatchOS, но получать UI- в MacOS, Android или UWP рассматривается совершенно по-другому, возможно, вовсе не как таблица, а скорее как двумерный массив значков/выборов для навигации по маршрутизатору. Ваше «Или [должно] ли мне [нужно] передать массив ViewModels в View и попросить View показать их?» почти попал в точку, за исключением того, что в архитектуре VIPER не используется термин ViewModel; вместо этого используйте слово сущность (т. е. чисто сущности домена приложения, отделенные от пользовательского интерфейса и ОС).
  • Codable — это интерфейс обработки JSON от Apple. Следовательно, его необходимо поместить в карантин в зоне взаимодействия для переносимости (реальной или предполагаемой для хорошей психической гигиены) на ОС, отличные от Apple. Входные данные (и выходные данные) интерактора JSON должны быть выражены в сущностях, которые являются исключительно доменом приложения без знания непереносимой среды, такой как Codable в SwiftUI. Потребуется переход от ориентированных на Apple способов представления результатов обработки JSON к способам представления этих эквивалентных сущностей исключительно в домене приложения.
person Andreas ZUERCHER    schedule 12.04.2021