我正在使用HTTP云函数，该函数返回JSONObject而不是快照值。在项目中，我之前使用过类似的库：
或
但是我只是注意到swift 4.1现在已经有了一个名为Codable Protocol的标准库，它应该比外部工具更具可定制性。
你们会推荐谁，为什么？
（使用非SQL数据库模型）
答案 0 :(得分：2)
这个问题很难回答，原因有几个，主要是因为它取决于个人喜好以及什么是从事您工作的最佳工具。
我曾经是SwiftyJSON的忠实拥护者，但是在Codeable出来之后，我进行了切换，主要是因为它对我的项目的依赖性降低了。 Swift会使其保持最新状态并使用最新功能。使用第三方框架，您必须等待所有者对其进行更新。
但是，我仍然在Swift的本机网络框架上使用Alamofire，因为我仍然必须围绕Swift版本构建包装器并进行维护。 Alamofire为我解决了这个问题；但是Codeable并非如此，我从来不需要围绕它构建自己的包装器。
我个人认为Codeable既快速又可靠，但这是我个人的选择。
答案 1 :(得分：1)
好吧，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，然后您可以简单地决定要使用的内容，我建议此article几乎满足您的情况
答案 2 :(得分：1)
最初，我是ObjectMapper的忠实拥护者，并在每个项目中都使用了它。但是最近我加入了一个团队，尝试至少使用第三方依赖项，您知道吗？我没什么区别。 （甚至在Codable推出之前）
使用JSON拆分两个任务：编码和解码：
编码简单明了。您只需要编写在字典中转换对象的方法即可。做完了您需要第三方吗？我不这么认为。
解码基本上是从字典启动对象。在这里，第三方可以通过使json的工作更小，更具表现力来提供帮助。
或者您可以在此处作弊并创建快捷方式：
extension Dictionary {
func get<T>(_ key: Key) -> T? {
return self[key] as? T
}
}
Person(
name: dict.get("name")
)
看起来像第三方赢了吗？我不确定。在大多数项目中，与处理业务逻辑，UI，动画，测试，代码审查等相比，使用JSON花费的时间很少。
现在您需要问自己，节省半小时和一百行代码值得引入新的依赖关系吗？您确定下一个将从事此项目的人会知道这个工具（他肯定会知道基本的知识）？您将等待多久才能使用新的迅速版本更新框架（不再有效）？
我个人认为这不值得。你的电话。