为什么模型对象不应该实现Swift的Decodable或Encodable协议

到目前为止，您可能在想：“他在说什么？Decodable和Encodable协议非常有用！”

我也同意你的看法。在Decodable和Encodable协议确实很有用。例如，Swift提供了一种本地方法来解析JSON元素或从 User Defaults 存储和检索对象，这是很棒的。没有什么问题。

但是，我认为我们在模型对象中使用这些协议会犯错。我将尝试解释原因。

---

领域模型和数据模型

领域模型（Domain Model） 是一种面向对象的模型，该模型合并了行为和数据。它代表了我们试图建模的业务规则。

数据模型（Data Model） 是持久性存储中的数据结构。它没有任何行为。

持久性存储的一些例子是 User Defaults ，Core Data ，文件，数据库，甚至是外部API。这些存储中的每个存储中的数据模型都可能不同。

领域模型和数据模型都包含数据，但是领域模型也包含业务规则。

领域模型中的对象应该不知道使用哪个持久性存储或数据模型。

这是因为领域模型和数据模型有不同的原因而改变。仅当执行业务规则或获得更多关于解决问题的见解时，领域模型才应更改。

另一方面，数据模型可能由于不同的原因而改变。例如，持久性存储需要从本地存储更改为远程API。领域模型不应受此基础结构更改的影响。

---

Decodable和Encodable

Decodable 协议用于对来自某些外部表示的对象进行 转化 。例如，它用于将JSON对象解析为结构体或类。

Decodable：一种可以从外部表示形式进行解码的类型。

另一方面，该 Encodable 协议用于将对象存储到某个外部表示中。例如，它可用于获取对象的JSON表示形式。

Encodable：可以将自身编码为外部表示形式的类型。

但是，为什么我们不可以使用Decodable或Encodable在我们的领域模型对象？

让我们用一个例子来回答这个问题。假设我们具有以下用户的JSON表示形式：

{ 
   “ first_name”：“ dick”，
   “ last_name”：“ richardson”，
   “ mail”：“ drichardson@enclave.com”，
   “ day_of_birth”：7026198103 
}

我们使用一个名为User的Decodable结构体解析JSON，并在我们的领域模型中表示一个User ：

struct User: Decodable {

  let firstName: String
  let lastName: String
  let email: String
  let dayOfBirth: Int
}

但是，如果JSON发生变化会怎样？假设现在first和last名称位于一个name 字段中：

{
   “ name”：{
      “ first”：“ dick”，
      “ last”：“ richardson”
   }，
   “ email”：“ drichardson@enclave.com”，
   “ day_of_birth”：7026198103 
}

由于此较小的更改，以前的User结构现在无法解析JSON数据。我们被迫更改领域模型以解析新的数据模型：

struct User: Decodable {
  
  let name: Name
  let email: String
  let dayOfBirth: Int
  
  struct Name: Decodable {
    
    let first: String
    let last: String
  }
}

好。现在，该User结构体解析新的JSON格式，但是我们必须更改firstNameandlastName的所有用法，分别将它们替换为name.first和name.last。

由于数据的更改，我们刚刚更改了领域模型。

这就是我不在我的领域模型对象中使用Decodable或Encodable的原因。

---

将领域模型与数据模型分开

我们需要做的是将领域模型与数据模型分离。

我们可以通过使用两个不同的类或结构体来实现。一个解析JSON，另一个代表领域模型对象。

struct User {

  let firstName: String
  let lastName: String
  let email: String
  let dateOfBirth: Date
}

struct UserDTO: Decodable {

  let name: NameDTO
  let email: String
  let dateOfBirth: Int
  
  struct NameDTO: Decodable {
    
    let first: String
    let last: String
  }
}

struct UserDTOMapper {
  
  static func map(_ dto: UserDTO) -> User {
    
    return User(firstName: dto.name.first, 
                lastName: dto.name.last, 
                dateOfBirth: Date(timeIntervalSince1970: dto.dateOfBirth))
  }
}

请注意，User该Decodable协议不再实现，因为它不用于解析JSON数据。User现在表示领域模型，并与数据模型分离。

我们创建了一个名为UserDTO（数据传输对象）的Decodable结构体，用于解析JSON数据。此结构体包含创建User所需的数据 。

最后，一个UserDTOMapper从UserDTO数据创建一个新的User。

---

优点

由于这种方法，领域模型不再与数据耦合，并且不需要每次数据模型更改时都进行更改。

当然，领域模型并非不受所有数据更改的影响。有时，模型仍然会改变。

在这种情况下，问问自己：“是迫使领域模型发生变化的数据还是其他？” 可能是业务规则发生了变化，领域模型也发生了变化，从而导致数据模型发生了变化。

将领域模型与数据分离的另一个优势是，领域模型变得更具表现力。我们可以用更 复杂的 类型，而不是只是普通的String，Int或其他Decodable类型。

在前面的示例中，现在的出生日期 在User结构体中以Date表示，与在UserDTO结构体中将出生日期表示为Int不同 。那些更复杂的类型可以在映射过程中创建。

---

Repositories仓库

既然我们知道了将域模型与数据分离的价值，我想介绍一个可以帮助我们实现目标的概念： repository仓库 。

可以将repository仓库视为元素的集合，可以在其中存储或检索它们。它提供了获取和存储这些元素的方法。

它是领域模型和数据模型之间的边界。这是一个 隐藏 使用的真正持久性存储及其所有实现细节的好地方，例如JSON解析和映射到领域模型对象。

示例

让我们来看一个例子：

// 1
protocol UserRepository {
  func getUser(completion: @escaping ((User?) -> Void))
}

// 2
class APIUserRepository: UserRepository {
    
  func getUser(completion: @escaping ((User?) -> Void)) {

    let session = URLSession.shared
    let request = createRequest()

    // 3
    let dataTask = session.dataTask(with: request) { data, response, error in
                                                    
      if let data = data {
        completion(createUser(from: data))
      }
      else {
        completion(nil)
      }
    }

    dataTask.resume()
  }

  private func createRequest() -> URLRequest {
    // Create the request
  }
  
  // 4
  private func createUser(from data: Data) -> User? {

      let decoder = JSONDecoder()
      decoder.keyDecodingStrategy = .convertFromSnakeCase

      guard let userDTO = try? decoder.decode(UserDTO.self, from: data) else {
        return nil
      }

      return UserDTOMapper.map(userDTO)
  }
}

这里发生了什么？

1. 仓库协议。使用协议是一个好主意，因为通过这种方式，可以使用 依赖注入 轻松地更改实际仓库的实现。名为UserRepository。该名称不应告诉我们有关所使用的持久性存储的任何信息。
2. 仓库实现。与协议不同，类的名称应为我们提供有关所选持久性存储的线索。在这种情况下，APIUserRepository使用外部API取回Users。
3. 仓库用于URLSession执行请求并获取User。我不想在这里进一步探讨细节，因为我不想错过这个例子的重点。如果您想了解有关网络使用的URLSession更多信息 ，可以在这里 看到一个很好的教程。
4. UserDTO结构体用于解析从API获得的JSON数据。如果将数据成功解析到DTO中，则UserDTOMapper从中创建一个User。如果解析失败，nil则返回。

就这样。很简单，对吧？

使用仓库时，非常容易更改使用的持久性存储。让我们这样做并将用户存储在本地。顾名思义，此新实现使用User Defaults来取回用户：

class UserDefaultsUserRepository: UserRepository {

  private let userDefaults = UserDefaults.standard
  private let userKey = "userKey"
  
  func getUser(completion: @escaping ((User?) -> Void)) {
    
    if let data = userDefaults.value(forKey: userKey) as? Data {
      completion(createUser(from: data))
    }
    else {
      completion(nil)
    }
  }

  private func createUser(from data: Data) -> User? {

    let decoder = JSONDecoder()
    decoder.keyDecodingStrategy = .convertFromSnakeCase

    guard let userDTO = try? decoder.decode(UserDTO.self, from: data) else {
      return nil
    }

    return UserDTOMapper.map(userDTO)
  }
}

请注意，此实现中使用的DTO与APIUserRepository中使用的相同 。当然，这不是强制性的。

每个实现都可以使用适合仓库需求的不同DTO。但是为了使示例简单，我使用了相同的。

---

结论

关于仓库的一件好事是，您可以将所有实现细节都隐藏在协议背后。

占用仓库的对象不必关心真正使用了哪种机制。它只关心仓库返回领域模型对象（ 在此示例中为User）。

而且，由于我们已经将领域模型与数据模型解耦，因此仓库实现可以更改，并且对系统的影响最小，因为返回的领域模型将保持不变。