领域模型模式 适应场景_具有适应设计模式的快速模型

领域模型模式 适应场景

Although it’s backend developer’s responsibility to make sure the API data is well-formatted, there is no harm to add a bit adapting logic in Model Layer

尽管后端开发人员有责任确保API数据的格式正确，但在模型层中添加一些自适应逻辑也没有什么害处

As an iOS app developer, when we receive the data from API, it’s better to always handle some except cases in JSON data such as row missing, null value and string converting etc.

作为iOS应用开发人员，当我们从API接收数据时，最好始终处理JSON数据中的某些情况，例如行丢失，空值和字符串转换等。

Personally, I always add extra code in Model Layer to either filter or convert some special cases to make sure the Logic/Viewmodel layer can receive the right data

就个人而言，我总是在模型层中添加额外的代码以过滤或转换某些特殊情况，以确保Logic / Viewmodel层可以接收正确的数据

Assume we have a bunch of JSON with some rows missing.

假设我们有一堆缺少一些行的JSON。

Comparing to the last object (“id”: “390”), the first(“id”: “1”) and second (“id”: “2”) JSON object has “year” and “mass” rows missing. Also, the fourth object(“id”: “370”) has “geolocation” JSON object missing.

与最后一个对象(“ id”：“ 390”)相比，第一个(“ id”：“ 1”)和第二个(“ id”：“ 2”)JSON对象缺少“年份”和“质量”行。 另外，第四个对象(“ id”：“ 370”)缺少“ geolocation” JSON对象。

Except that, we may have to split the string(“year”: “1951–01–01T00:00:00.000”). Although these works can happen in Logic/ViewModel layer, it makes more sense if simple operations can be done in the Model layer.

除此之外，我们可能必须拆分字符串(“ year”：“ 1951–01–01T00：00：00.000”)。 尽管这些工作可以在Logic / ViewModel层中进行，但如果可以在Model层中完成简单的操作，则更有意义。

In addition, Swift encourages functional programming which saves plenty of code. Therefore, even if we applied a lot of logics in Model, it still looks clean.

此外，Swift鼓励使用函数式编程，以节省大量代码。 因此，即使我们在模型中应用了很多逻辑，它仍然看起来很干净。

Overall, I think it reasonable to take off a bit of responsibility to avoid the Massive ViewModel/Logic Class.

总的来说，我认为有责任避免使用大量的ViewModel / Logic类是合理的。

Here is my code to handle this special JSON:

这是我处理此特殊JSON的代码：

1: We have a protocol to present the necessary data to Logic/ViewModel Layer as sometimes we don’t need to process all the API data. Meanwhile, we can set only “get” access to the values if necessary.

1：我们有一个协议可以将必要的数据呈现给Logic / ViewModel层，因为有时我们不需要处理所有API数据。 同时，如果需要，我们只能对值进行“获取”访问。

2: We have the Model implement Decodable protocol to be ready for converting API data. I highly recommend copying the API data to this web to get the Model you need:

2：我们具有模型实现可分解协议，可用于转换API数据。 我强烈建议您将API数据复制到此网站，以获得所需的模型：

This will save you plenty of time to check through all JSON attribute to find special cases.

这将为您节省大量时间检查所有JSON属性以查找特殊情况。

3: After data retrieved from API, we have extensions implemented the Meteorite Protocol to apply some light logics. As we can see from above, we can have logic binding to the value to handle Null, Missing and string processing.

3：从API检索数据后，我们已对扩展程序实施了Meteorite协议以应用一些轻逻辑。 从上面可以看到，我们可以将逻辑绑定到该值以处理Null，Missing和字符串处理。

Here are the advantages of applying this pattern:

这是应用此模式的优点：

• In the Logic/ViewModel Layer, we only initialise the Meteorite Object to get the conventional data
  在Logic / ViewModel层中，我们仅初始化Meteorite对象以获取常规数据
• If the API gets updated, we don’t have to bother the ViewModel code. We can just update the code in the Model layer.
  如果API得到更新，则无需打扰ViewModel代码。 我们可以只更新Model层中的代码。
• By doing this, we followed one of the SOLID principals — Interface segregation principle as we only present the necessary methods and variables to the upper layer
  通过这样做，我们遵循了SOLID原则之一-接口隔离原则，因为我们仅向上层展示了必要的方法和变量

If you know the design pattern, you will see this is the adaption Design Pattern which allows the interface of an existing class to be used as another interface without modifying the source code.

如果您知道设计模式，则将看到这是适应性设计模式，它允许将现有类的接口用作另一个接口，而无需修改源代码。

If you are interested in reading any of my other articles, you are welcome to check them out in my profile. If you’ve any questions, comments or suggestions please hit me up on Linkedin.

如果您有兴趣阅读我的其他文章，欢迎在我的个人资料中查看。 如果您有任何疑问，意见或建议，请在Linkedin上打我。

翻译自: https://medium.com/dev-genius/the-swift-model-with-adaption-design-pattern-6ac0b84cdd18

领域模型模式 适应场景