VM
ну по хорошему отсюда начинать надо?
Size: a a a
2021 August 11
DK
ну можно конечно поиском как вы, но потом все равно нужно глазами смотреть по коду. нужно найти сетевой слой и его переписывать. плюс конечно все зависимости от него
VM
а под сетевым слоем можете уточнить что именно? чтобы я хоть понимал куда смотреть, а то проект новый пока чуть не втыкаю что где как)
DK
спрашивайте у разработчика который его делал. под сетевым слоем я имел ввиду набор кода для работы с сетью, обычно логически связанные части кода объединяются в общие группы в проекте, это удобнее чем поиск по ключевым словам
D
Добавить доп слой моделей и трансляторов
VM
к сожалению в туториале ничего такого не вижу
нашёл что то типа когда у меня к примеру какое то свойство не соответствует codable то мол следуем привести к нему через init/encode
это из этой песни?
нашёл что то типа когда у меня к примеру какое то свойство не соответствует codable то мол следуем привести к нему через init/encode
это из этой песни?
DK
имхо, туториалы пишутся чтобы легко понять основы работы с какой-нибудь библиотекой. а разделение моделей объектов для хранения данных и объектов для передачи по сети - это вопрос архитектурный. поэтому в туториале о нем не говорится. подразумевается что вы это и так знаете
VM
ну разве тип(RealmOptional<Bool>()) той или иной модели не в основе должен быть?
ну то есть я вижу они описали какие типа данных поддерживают, а что делать с остальными хз)
пока не нашёл
ну то есть я вижу они описали какие типа данных поддерживают, а что делать с остальными хз)
пока не нашёл
DK
спрашивайте у разработчиков библиотеки. я реалм не пользую, не могу ответить
D
Нет. Можно запилить кастомный конструктор и энкодер, но это плохая практика. Хорошая практика это использовать DTO и разделить сетевой слой от слоя хранения https://medium.com/geekculture/using-data-transfer-objects-dto-in-swift-code-6436c0ca9098
V
С чего это кастомные энкодеры-декодеры плохая практика?
D
смотрите в контексте - это приведет к смешиванию сетевого слоя и слоя хранения. Со всеми вытекающими.
V
Разве лучше писать в два раза больше моделей, чем просто написать кастомный декодер?
D
можно не писать, можно генерить если уж прямо очень не хочется. Но ответ да - лучше в два раза больше кода, и в пять раз больше кода, если слои при этом останутся раздельными.
V
у меня на одном из проектов так, и я решительно никак не могу прочувствовать преимущества, только бойлерплейт постоянно писать по переводу из dto в нужные модели, которые совпадают на 100% по пропертям. Может конечно проект не настолько большой, чтобы я понял нафига это сделано
D
Преимущества видны при: 1) если больше одного разработчика, 2) если поддерживаете проект год и больше, 3) если проект достаточно сложный, 4) при любом рефакторинге, 5) при дебаге. Особенно если у вас Realm :), с реалмом шутки плохи, особенно при многопоточности
V
а с Realm какие проблемы в данном случае? Ну перевожу я dto в объект realm или сразу декодирую ответ в объект realm, в чем сложности и подводные камни?
D
Объект реалм надо менять в том же потоке, в котором он был создан. Если вы сетевые запросы делаете в отдельном потоке (а я надеюсь, что это так :)), то вы будете иметь креш.
V
ну его не обязательно записывать в реалм в момент создания. И да, понятное дело, что сетевые запросы в бекграунде гоняются )
D
а еще можно разделить слои и забыть про эту особенность. Собтвенно для чего и придуман SOLID и все нормальные архитектуры.