我尝试在应用程序设计中更多地采用 Swift 的值类型，但我遇到了一些初学者困难。我知道那些基于意见的 StackOverflow 格式通常不太受欢迎，但我认为这里有可能不是特别主观的最佳实践。
我理解结构的所有理论上的好处，关于避免共享可变状态，使实现“撤消”变得容易的复制行为等，但我在实践中很难在我的应用程序的模型层中使用它（其中我认为结构是最有益的）。我什至不知道这是否值得追求，所以请耐心等待。
假设我有一个集合视图，其条目模型图片及其元数据。选择图片后，它将显示一个详细信息视图，让您查看和编辑图片及其关联元数据（文件名、GPS 位置、描述、标签等）的详细信息。
我正在努力解决如何设计详细视图控制器和存储所有图像存储库的模型层之间的交互。
以下是我关于如何设计视图层和模型层之间的交互的一些想法。
-
视图控制器可以给模型层所拥有的模型起别名。也就是说，模型层将保存模型对象的集合。当选择其中一个时，VC 将向模型层询问其中一个对象，该对象将通过引用返回。当用户更改图像的详细信息时，VC 的别名引用将用于访问“活动”模型对象，并直接更新它。
这听起来像是最简单的方法，并且可能是我在其他语言（如 Java）中会做的，但它迫使我使用class为我的对象建模，否则struct似乎更合适。在这种情况下，（对我来说）似乎不需要身份。如果两个图片对象具有相同的字段，则它们是无法区分的。
-
如果我尝试将模型保留为结构，我的视图控制器可以使用复制-修改-写入模式。
- 当选择图像进行编辑时，其模型将被复制到 VC 中。
- VC 作用于其本地副本，就地改变它
- 最终，当需要保留更改时（例如切换到新图像进行编辑、退出应用程序等），VC 将使用其本地副本覆盖模型层的值。
这消除了方法 1 中共享可变状态可能带来的任何潜在线程问题，但它也带来了模型与 VC 不同步的缺点，这可能会导致各种一致性问题。
接下来的 3 种方法考虑使用诸如 Joint 或 Rx 之类的反应式框架的想法。我可以使用此模式来订阅我的 VC，以接收模型层及其更改的更新Picture对象。但是，我不确定“其他方式”如何运作； VC 如何通知模型进行更新。如果我让模型自己订阅视图，那么我认为我会出现无限循环，除非我添加了一些机制，哪些更改应该触发观察者，哪些不应该触发观察者。
我不确定哪一个是最好的，我怀疑这是你凭经验学到的东西之一（我还没有：P）。任何指导将不胜感激！
None
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
