Ish*_*war 3 mvvm swift swiftui
我对 SwiftUI 中的应用程序开发有点陌生。在过去的 2-3 个月里，我开发了一些小的 iOS 应用程序只是为了学习概念。否则，我是 C#、Java 等方面经验丰富的开发人员。
我对 SwiftUI 不太确定的一件事是围绕为项目开发类的正确架构集。我的意思是可能有几种方法
假设我正在编写一个库存管理应用程序，所以如果模型之一是商品，那么它的属性可以是 Id、名称、价格、条形码等。在我看来，模型类不应该像 @Published、@ObservableObject 这样关心 View， @State、@EnvironmentObject 等等等等。模型应该只坚持代表域。正确的？
理想情况下，模型类应该写为 Class 而不是 Struct（如果我将我对 OOPS 的理解从 C++ 延续到 Java/C#，在那里我们编写类而不是结构）
现在在模型类（假设它们是类，或者为了 SwiftUI 框架，我们最多将它们设为 Struct）和 View 类之间，必须进行大量通信、状态更改、事件处理，以使应用程序值得做一些事情。我的意思是处理用户手势，创建和编辑数据，当用户在 UI 之间来回导航时，这些数据应该更新屏幕。
我发现将模型（如果它们以纯粹的形式开发）和视图连接起来并不困难。从某种意义上说，当我开始编写视图并寻求实现涉及数据编辑、反映视图更改等的用例时，我发现纯模型类是不够的。它们必须进行修改以反映 SwiftUI 功能，如绑定、可观察性、发布以在视图和模型之间以及两个模型之间同步数据。
想知道在模型和视图之间连接和通信的正确设计模式是什么？MVVM 是在基于 SwiftUI 的项目中使用的正确设计模式吗？如果不是那么还有什么是正确的模式？
如果 MVVM 是正确的模式，那么是否有任何质量指南或资源或示例 SwiftUI 项目（gitHub？？）我可以查看和学习？
我认为你的假设是错误的。
理想情况下，模型类应该写为 Class 而不是 Struct
区分有状态和无状态的模型。
没有状态的模型应该是值类型。
带状态的模型应该是引用类型。
我们需要的第二组类是视图，即继承自 View。毫无疑问，这些必须是 Struct，因为 SwiftUI 框架以这种方式工作。
值类型不能被继承。我也认为它们是模型而不是视图。
例如; struct Model: View {}
它们是模型，可用于构建视图，因此符合视图。
它是值类型的事实也支持它不是视图。（不能继承）
不管你的模型有没有状态，只要符合View，就可以用来渲染一个视图。这是 SwiftUI 的设计，取自 React，IMO 的一个页面。（我个人不认为 React 会为 MVVM 烦恼）
现在，既然您认为 Model 应该严格没有状态，那么您就有问题了。
您需要一个引用类型对象来处理所有状态并将其桥接到视图。
您可以关注 MVVM。在这种情况下，您将失去大部分围绕 构建的 SDK 支持struct Model: View，例如；@State、@StateObject、@EnvironmentObject和相关的自动绑定和安全检查。您还将为每个视图添加至少一种引用类型，并将大部分控制/业务逻辑放入其中。（你还能把它放在哪里？）
所以它实际上是一个视图控制器。并且您将在引用类型对象上执行大部分 Control 工作，而没有不变性的安全保护。这是您将引入的所有管理费用之上的；并且由于您将传递视图模型以使其“可重用”，因此您将拥有由具有隐式状态的共享引用引起的所有常见错误。
当然，对我的上述评估持保留态度。
或者你可以做官方指南做的事情：struct Model: View {}在其中包含可能的状态。
这里的关键，因为 SDK 要求您添加额外的注释，是明确标识状态对象。例如; @StateObject, @ObservableObject. 并且您必须创建与模型分开的引用类型对象。它基本上消除了视图模型的中间人。
我认为这是 MVVM 开发人员最难习惯的事情。您不再需要视图模型来执行视图模型所做的工作。
但不是应该很明显吗？视图模型取决于绑定的设计方式。如果 SwiftUI 具有如此高效的绑定设计（它在没有额外对象的情况下声明性地这样做）视图模型可能是自动的。
SwiftUI 去掉了 UIViewController，是不是就不能有 Control 了？
我没有看到 MVC 开发人员出来Controller为每个视图创建一个。
同样的道理，你可以在没有 VM 的情况下拥有 MVVM。设计模式是一种@State心态。
总结一下：
我认为最好的架构是官方 SDK。在跑步之前先学会走路。
传统意义上的 MVVM 也是一种选择。但我认为你需要考虑的可能性
传统智慧不是最新的SDK。