欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识！
您现在的位置是： 首页

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

程序员文章站 2024-02-20 15:37:34
...

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

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

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

领域（Domain）模型和数据（Data）模型

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

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

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

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

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

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

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

Decodable和Encodable

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

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

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

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

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

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

{ 
   “ first_name”：“ dick”，
   “ last_name”：“ richardson”，
   “ mail”：“ [email protected].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”：“ [email protected].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）。

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

相关标签： iOS开发架构 ios objective-c swift xcode

上一篇： Swift 3.0 基础部分

下一篇： 网页抓取信息（php正则表达式、php操作excel）

推荐阅读