Использование Codable Protocol или внешнего инструмента для отображения JSON

Question

Я использую функцию облака HTTP, которая возвращает JSONObject вместо значений снимка.В проектах до этого я использовал библиотеки для этого, например:

• https://github.com/tristanhimmelman/ObjectMapper

или

• https://github.com/SwiftyJSON/SwiftyJSON

Но я только что заметил, что в swift 4.1 теперь есть стандартная библиотека для этого именуемого Codable Protocol, которая должна быть более настраиваемой, чем внешние инструменты.

Что вы, ребята, порекомендуете и почему?

(с использованием модели базы данных не в базе данных)

Answer 1

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

Раньше я был большим поклонникомSwiftyJSON, но после выхода Codeable я сделал переход в основном потому, что это было на одну зависимость меньше для моих проектов.Swift поддерживает его в актуальном состоянии и работает с новейшими функциями.При использовании стороннего фреймворка вам придется дождаться их обновления владельцами.

Однако я все еще использую Alamofire поверх собственной сетевой инфраструктуры Swift, потому что мне все равно придется создавать оболочку вокруг версии Swiftи поддерживать это.Alamofire позаботится об этом для меня;однако это не относится к Codeable, мне никогда не приходилось создавать свою собственную оболочку вокруг него.

Лично я бы выбрал Codeable, это быстро и надежно, но это мой личный выбор.

Answer 2

Intro

Изначально я был большим поклонником ObjectMapper и использовал его в каждом проекте.Но в последнее время я попал в команду, которая пытается использовать сторонние зависимости как минимум, и знаете что?Я не вижу никакой разницы.(даже до выхода Codable)

Работа с JSON разделяется на 2 задачи: Кодирование и декодирование:

Кодирование

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

Декодирование

Декодирование в основном инициирует ваш объект из словаря.И здесь могут помочь третьи стороны, сделав работу с JSON меньше и выразительнее.

Или вы можете обмануть здесь и сделать ярлык:

extension Dictionary {
    func get<T>(_ key: Key) -> T? {
        return self[key] as? T
    }
}
Person(
    name: dict.get("name")
)

Заключение

Похоже, выигрывают третьи лица?Я не уверен.В большинстве проектов время, которое вы тратите на работу с JSON, так мало по сравнению с работой над бизнес-логикой, пользовательским интерфейсом, анимацией, тестированием, проверкой кода и т. Д.

Теперь вам нужно спросить себя, экономит ли полчаса и сто строккода стоит ввести новую зависимость?Вы уверены, что следующий человек, который будет работать над этим проектом, будет знать этот инструмент (он определенно будет знать основы Swift)?Как долго вы будете ждать обновления фреймворка с новой версией swift (уже не так)?

Для себя я решаю, что оно того не стоит.Ваш звонок.

Answer 3

Ну, Codable - это typealias, а не protocol,

/// `Codable` is a type alias for the `Encodable` and `Decodable` protocols.
/// When you use `Codable` as a type or a generic constraint, it matches
/// any type that conforms to both protocols.
public typealias Codable = Decodable & Encodable

. Это вопрос о себе, но я расскажу о том, почему Codable, для меня меньшеэто зависимости, тем лучше.

Codable сильный, но все еще ограничен некоторыми точками,

Codable устраняет необходимость в любой функции инициализации, учитывая, что мы довольны свойствами нашего объекта, имеющими то же имя, что иих ключи JSON и могут предполагать, что данные JSON имеют тот же формат, в котором мы ожидаем, что свойства объекта будут находиться в нем (т. е. строки с заглавной буквы, URL-адреса со схемами или без).

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