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