Apple在Data Essentials in SwiftUI WWDC 2020 at 4:18中解决了这个问题
EditorConfig可以维护其属性的不变量，并可以独立测试。而且因为EditorConfig是一个值类型，所以对EditorConfig属性的任何更改（如其进度）都可以作为对EditorConfig本身的更改而可见。四点十八分
所以在你的例子中，它看起来像：

struct MyConfig {
    var money: String = ""
    var desc: String = ""
    var showDatePicker: Bool = false
    var showingAlert: Bool = false
    var showConstantlyAlert: Bool = false
    var showKeyPad: Bool = false
    var showCatesPanel: Bool = false
    var selectedCate: String = ""

    mutating func otherLogic() {}
}

struct MyView {

    @State var config = MyConfig()
    @FocusState var isDescFieldFocused: Bool

我想让你知道，MVVM（i.视图数据使用对象）不适合SwiftUI，因为View结构和属性 Package 器相当于视图模型对象，但更快，更不容易出错。如果你使用实际的对象而不是学习SwiftUI的特性，你会遇到问题。
我们在SwiftUI中使用ObservableObject的时间是用于模型数据，即。即环境对象/单例，其将模型结构的数组存储在@Published属性中，并负责加载/保存/同步等。模型数据等。这是涵盖在同一视频稍后，从大约9分30秒。
对于模型数据的写访问，我们使用@Binding。
当我们需要一个引用类型作为状态时，我们也使用@StateObject。例如，对于生命周期与屏幕上的东西（如网络）相关的异步功能，但现在我们有.task(id:)修饰符来实现同样的事情，这几乎是多余的。因为我们可以简单地将await的结果（或抛出的错误）设置为@State，当视图消失时，任务将自动取消（如果传递给task(id:)的id发生了变化，任务也会被取消并重新启动）。在@StateObject中重新实现该行为需要大量的代码和测试。

正如您所说，您可以为该视图创建一个视图模型，它可以是@StateObject或@ObservedObject（取决于您是想在视图中创建视图模型还是从外部注入视图模型）。
我倾向于为我的视图创建视图模型，如果它们需要任何逻辑，而不仅仅是显示从父视图传递下来的信息。
因此，您可以这样做：

final class YourNameViewModel: ObservableObject {

    @Published var money = ""
    // other properties

    init() {
        ...
    }

}

并在视图中使用它，如下所示：

struct YourNameView: View {

     @StateObject var vm = YourNameViewModel()
     // or @ObservedObject var vm: YourNameViewModel (if you want to pass it down from a parent view)    

}