Что такое DataSource Model?

Я надеюсь, что при изучении языка Swift или Objective-C вы наверняка уже слышали это слово, или даже используете принцип DataSource в своих проектах. Возможно вы уже используете этот принцип, но называете его по другому, так или иначе суть одна и тоже. Когда я понял данный принцип работы, создание многих вещей стало на столько простым, что вещи где мы писали множество строк кода, сокращались просто в десятки раз. Ладно, не буду вас утомлять, поехали 🙂

Я думаю, что вы уже догадались что речь пойдет сейчас про таблицы и коллекции. Ведь там упоминается данное словосочетание, но многие вообще не обращают внимание, почему Apple разделяет смысл UITableViewDelegate и UITableViewDataSource. Да можно понять что там данные, а там что-то другое. Это отчасти так, но никто не задумается какие именно данные.

В данной статье я немного введу в курс дела, что такое это dataSource модель, так как я готовлю сейчас цикл статей где покажу на живом примере, как это все можно использовать в бою.

Наблюдая за рекомендациями, примерами в книгах, мануалах и разного рода курсах, множество людей немного заблуждаются опять-таки в разделении данных от вывода.

Самой распространенной проблемой, есть передача модели данных в ячейку. Я не скажу что это грубейшая ошибка, и приложение ваше не будет правильно работать, но это нарушает принципы концепции правильной архитектуры которые я описывал в предыдущих статьях. Пример кода:


func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let cell = tableView.dequeueReusableCell(withIdentifier: "Cell") as! CustomTableViewCell
    cell.configure(data[indexPath.row])
    
    return cell;
    
}

Такой подход еще где-то как-то, возможно уместен в Objective-C но точно не в Swift, так как в основном при правильном проектировании все модели данных в Swift должны быть структурами, а так как структура у нас копируется при присваивании, то что уходит в ячейку уже нам абсолютно не пригодное для каких нибудь манипуляций в будущем. Ах, да, если у вас таблица имеет смысл только показать значения, то заморачиваться возможно так не нужно, но я бы рекомендовал даже если и такой случай как просто вывод данных, научить себя строить таблицы изначально правильно. Так как практика показывает что все что в начале было простым, становиться сложным в будущем. И правильный фундамент сейчас залог успеха в будущем.

Использование DataSource моделей уместно в первую очередь в тех случаях когда наша таблица имеет больше функциональности нежели стандартный вывод текста. Самое распространение случаи это формы ввода данных. Такими есть страница авторизации, регистрации, настройки и т/д. в таких интерфейсах в основном используют таблицы. И вот для взаимодействия данных которые нам нужно показать/изменить с помощью пользовательского интерфейса как раз так и нам приходясь DataSource модели.

Грубо говоря, DataSource модель, это модель данных сугубо для нашей с вами таблицы. Это модель которая имеет свои дополнительные данные помогающие рендерить правильно таблицу, которых не должно быть в основной модели данных используемой в приложении. К примеру у нас есть тип данных User, но мы не можем сконфигурировать нашу таблицу исходя только этого типа данных, так как наша таблица нуждается в дополнительных значениях.

Многие разработчики называют еще данный тип как viewModel, но я называю вещи своими именами – dataSource model.

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

P.S: Такие модели очень сильно помогают при создании прототипов, когда уже существует дизайн приложения. Мы можем быстро создать прототип, без участия бекэнда, и потом подключить его за “пару минут” не трогая вообще нашу таблицу.

Поделиться

Оставить комментарий