为 SwiftUI 应用程序设计类的正确架构是什么

Question

我对 SwiftUI 中的应用程序开发有点陌生。在过去的 2-3 个月里，我开发了一些小的 iOS 应用程序只是为了学习概念。否则我是 C#、Java 等方面经验丰富的开发人员。

我不太确定 SwiftUI 的一件事是围绕为项目开发类的正确架构集。我的意思是可能有几种方法

1. 我们编写模型类来表示我们的应用程序需要保存的数据。在纯粹的形式中，模型类应该只关心数据，我的意思是模型类应该只包含反映数据的属性。

假设我正在编写一个库存管理应用程序，因此如果其中一个模型是商品项目，那么它的属性可能是 ID、名称、价格、条形码等。在我看来，模型类不应该像 @Published 那样关注 View 的问题， @ObservableObject、@State、@EnvironmentObject 等。模型应该只坚持代表域。对吗？

理想情况下，模型类应该写成 Class 而不是 Struct（如果我将我对 OOPS 的理解从 C++ 转移到我们编写类而不是结构的 Java/C#）

1. 我们需要的第二组类是视图，即继承自 View。毫无疑问，这些必须是 Struct，因为 SwiftUI 框架是这样工作的。

现在在模型类之间（假设它们是类，或者为了 SwiftUI 框架，我们最多将它们设为 Struct）和视图类，大​​量的交流，状态变化，事件必须发生才能使应用程序值得做某事。我的意思是处理用户手势、创建和编辑数据，当用户在 UI 之间来回导航时应该更新屏幕。

我发现连接模型（如果它们以纯粹的形式开发）和视图有点困难。从某种意义上说，当我开始编写视图并希望实现涉及数据编辑、反映视图变化等的用例时，我发现纯模型类是不够的。必须修改它们以反映 SwiftUI 功能，例如绑定、可观察性、发布以在视图和模型之间以及两个模型之间同步数据。

想知道在模型和视图之间连接和通信的正确设计模式是什么？ MVVM 是在基于 SwiftUI 的项目中使用的正确设计模式吗？如果不是，那么还有什么是正确的模式？

如果 MVVM 是正确的模式，那么是否有任何质量指南或资源或示例 SwiftUI 项目（gitHub？？）我可以查看和学习？

Answer 1

我认为你的假设是错误的。

理想情况下，模型类应该写成 Class 而不是 Struct

区分有状态和无状态的模型。

没有状态的模型应该是值类型。

有状态的模型应该是引用类型。

我们需要的第二组类是视图，即从视图继承。毫无疑问，这些必须是 Struct，因为 SwiftUI 框架是这样工作的。

值类型不能被继承。我也认为它们是模型而不是视图。

例如; struct Model: View {}

它们是模型，可用于构建视图，因此符合视图。

它是值类型的事实也支持它不是视图。 （不能继承）

不管你的模型有没有状态，只要符合View，就可以用来渲染视图。这是 SwiftUI 的设计，借鉴了 React, IMO。 （我个人认为 React 从来没有打扰过 MVVM）

既然你认为 Model 应该是严格没有状态的，那么你就有问题了。

您需要一个引用类型对象来处理所有状态并将其桥接到视图。

您可以关注 MVVM。在这种情况下，您将失去大部分围绕 struct Model: View 构建的 SDK 支持，例如； @State、@StateObject、@EnvironmentObject，以及相关的自动绑定和安全检查。您还将为每个视图添加至少一个引用类型，并将大部分控制/业务逻辑放入其中。 （你还能把它放在哪里？）

所以它实际上是一个视图控制器。而且您将在引用类型对象上完成大部分控制工作，而没有对不变性的安全保护。这是您将引入的所有间接费用的基础；并且由于您会将视图模型传递给“可重用”，因此您将遇到由共享引用和隐式状态引起的所有常见错误。

当然，对我的上述评估持保留态度。

或者您可以按照官方指南执行的操作：struct Model: View {}，其中包含可能的状态。

这里的关键是，因为 SDK 要求您添加额外的注释，所以状态对象是明确标识的。例如。; @StateObject，@ObservableObject。而且您必须创建与模型分开的引用类型对象。它基本上切断了中间人，即视图模型。

我认为这是 MVVM 开发人员最难适应的事情。您不再需要视图模型来完成视图模型的工作。

但这不应该很明显吗？视图模型取决于绑定的设计方式。如果 SwiftUI 的绑定设计如此高效，（它以声明方式这样做，没有额外的对象）视图模型可能是自动的。

SwiftUI 去掉 UIViewController，是不是就不能拥有 Control？

我没有看到 MVC 开发人员出来为每个视图创建一个 Controller。

同样的道理，你可以在没有 VM 的情况下拥有 MVVM。设计模式是一种@State 的想法。

总结一下：

我认为最好的架构是官方 SDK。先学走路再跑。

传统意义上的 MVVM 也是一种选择。但我认为你需要考虑这种可能性

传统智慧与最新的 SDK 不同步。