Я впервые пишу приложение на архитектуре VIPER и не могу понять, должны ли методы UITableView
делегата и источника данных входить в представление, презентер или интерактор? Я нашел в некоторых ссылках, что это должно быть частью класса View, но это не похоже на то. И даже если это часть View, как данные туда попадут, потому что View технически не должен запрашивать данные у докладчика. Presenter должен сам передавать данные.
Реализация делегата UITableView и источника данных в VIPER
Ответы (3)
Да, источник данных и делегат являются частями уровня представления.
Если вы не хотите, чтобы ваше представление запрашивало данные у ведущего, вы можете сделать это так, как я это описываю. Класс источника данных содержит viewModels (фиктивные объекты). Затем вы можете общаться через интерфейс. Я имею в виду, что вы могли бы лучше понять на каком-то примере:
protocol SomeViewProtocol {
func set(withVMS vms: [SomeViewModel])
}
final class SomeVC: SomeViewProtocol {
let dataSource: SomeDataSource
let tableView: UITableView
override func viewDidLoad() {
tableView.dataSource = dataSource
}
func set(withVMS vms: [SomeViewModel]) {
someDataSource.set(withVMS: vms)
tableView.reloadData()
}
}
protocol SomePresenterProtocol {
...
}
final class SomePresenter: SomePresenterProtocol {
fileprivate let view: SomeViewProtocol
//After view did load
func initAfterLoad() {
.
.
.
view.set(withVMS: viewModels)
}
}
Но, с моей точки зрения, нет ничего плохого в том, что View запрашивает данные у докладчика.
Ссылка, которую вы прочитали, верна, методы делегата и источника данных для UITableView
в приложении с архитектурой VIPER должны оставаться в View
. Что касается вашего вывода о том, как данные попадут в представление, это неправильно, потому что View
сам должен запросить Presenter
принести данные, а затем Presenter попросить Interactor
загрузить данные из Интернета или базы данных. Если у вас есть какие-либо вопросы об архитектуре VIPER, я определенно рекомендую эти статьи:
Статья 1: https://blog.mindorks.com/building-ios-app-with-viper-architecture-8109acc72227
Статья 2: https://cheesecakelabs.com/blog/best-practices-viper-architecture/
Статья 3: https://cheesecakelabs.com/blog/ios-project-architecture-using-viper/
Допустимо оставить источник данных в представлении (и, вероятно, это правильное место, если мы не рассматриваем никакие другие слои). Однако это не на 100% правильно с точки зрения SOLID. VIPER был создан для продвижения принципа единой ответственности. Оставление источника данных/делегата таблицы в View
вполне может привести к нарушению этого принципа из-за кода, не связанного с представлением, что потенциально возможно в делегате/источнике данных. Гораздо лучше ограничить View тем, чтобы он только отвечал за задачи, связанные с View. В идеале он не должен служить поставщиком данных, даже источником данных для табличного представления. Тем не менее, лучше всего реализовать табличное представление DataSource/Delegate отдельно от Presenter и View. Объявите источник данных (делегата) в View и назначьте его своей таблице:
let dataSource: DataSource! // Implements both TableView DataSource and Delegate protocols
let tableView: UITableView!
override func viewDidLoad() {
tableView.dataSource = dataSource
tableView.delegate = dataSource
}
Затем этот источник данных будет связываться либо с представлением, либо с докладчиком (при необходимости) через протоколы вывода, как это принято в VIPER.
DataSource получает данные от Presenter, но не сам по себе, а через View, который получает данные от Presenter. выходной интерфейс. Последнее иногда обсуждается и зависит от сложности вашего приложения. Можно объединить Presenter и tableview DataSource с протоколами связи, и это может быть хорошо реализовано, но это зависит от подхода, принятого в вашей команде. VIPER предназначен для управления большими проектами, и его методы должны быть удобны для всей вовлеченной команды.