Реализация делегата UITableView и источника данных в VIPER

Да, источник данных и делегат являются частями уровня представления.

Если вы не хотите, чтобы ваше представление запрашивало данные у ведущего, вы можете сделать это так, как я это описываю. Класс источника данных содержит 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 предназначен для управления большими проектами, и его методы должны быть удобны для всей вовлеченной команды.