небольшое, 5 страниц примерно. Я работаю со сторонним API и мне нужно передавать token, user info и прочую информацию между страницами, с помощью чего это лучше делать?
Стейт менеджер
Вся эта инфа хранится в классе апи, у каждой страницы есть viewModel, она берет из апи класса нужную информацию и передаёт у свою view страницу
Для передачи логики запросов создайте отдельный класс - репозиторий. Поместите репозиторий в контекст/сервис локатор. Репозиторий API передайте в стейт менеджер. В стейт менеджере выполните логику получения и обработки данных и обработки ошибок. Во view обратитесь к стейт менеджеру и получите уже подготовленные данные. В качестве провайдера зависимостей или provider или get_it
Вся инфа хранится в data слое. Потом модель из дата слоя перегоняется в модель domain слоя и ложится внутрь вьюмодели
Чем конкретно выражен в проекте дата и домейн слои?
data слой - респонсы с сервера, либо объекты в локальной бд. Учитывай, что у тебя для масштабируемости эти две модели должны быть разными
Поясни за DDD, пожалуйста, мне тоже интересно
Но это просто классы с методами так? Но то что данный слой относить к дата слою это я просто у себя в голове заметку делаю, или надо как то реализовать ?
Тут долго писать, лучше поищи статьи/книги по этому поводу. Грубо говоря - это когда ты сначала пилишь бизнес-логику и вьюхи, а только потом соединяешь с сервером
data - классы обычно иммутабельны, не содержат логики и предназначены только для хранения данных, У C# и Kotlin это реализовано через специальный модификатор record/data, а всякие Go и Rust вообще используют стурктуры
это ведь можно считать за репозиторий?
+/-, еще с моделями данных
Тоже не совсем так. Дата классы содержат в себе опциональные поля. Т.е. идет акцент на том, что апи поменяется, и какая-то инфа не долетит. Домен же - наоборот хранит в себе только поля, которые не могут быть null. При этом обе модели - иммутабельные (в идеале, на практике не вижу ничего плохого в том, чтобы пара полей домена была мутабельными для определенных случаев)
Ну, точнее не так. Сначала ты смотришь на дизайн, смотришь, какие поля и какие сущности тебе нужны для реализации экрана. Потом составляешь эту модель данных, мокаешь ее, пилишь дизайн. И только потом ты смотришь на то, что прилетает с сервера и перегоняешь эту инфу в сущность, которую спроектировал ранее. Этот подход полезен для параллельных команд разработки ё
Слой можем содержать несколько файлов и классов ?
Конечно. Это же абстракция
Обсуждают сегодня