SwiftUI应用转SwiftData：单@Model类与多实体模型哪种可行？

方案A：独立模型+@Query替代计算属性 #

• 完全可行，这是SwiftData官方推荐的常规实践：
  • 给Landmark、Hike分别添加@Model修饰，将它们定义为独立的SwiftData持久化模型。原features计算属性可直接用@Query替代：

    @Query(filter: #Predicate<Landmark> { $0.isFeatured }) 
    var features: [Landmark]
    

    分类数据categories可以通过@Query获取所有Landmark后，在视图或工具类中做分组处理。
  • 单例Profile的处理：
    • 若无需持久化，保留原@Observable修饰，通过@Environment注入或全局单例的方式在应用内共享；
    • 若需要持久化，给Profile添加@Model，在视图中用@Query(fetchLimit: 1)获取唯一实例，首次启动时检测到无数据则插入Profile.default。
  • 工具函数分散问题：可将原ModelData中的通用逻辑（如JSON加载、分类分组）抽成全局工具类或模型扩展（比如给Landmark添加静态方法处理分类），保证代码的集中性。

方案B：直接给ModelData添加@Model #

• 编译通过但存在严重缺陷，不建议使用：
  • 编辑更新问题：SwiftData将整个ModelData视为单一实体，内部的landmarks、hikes数组会被序列化为二进制数据存储，而非建立关联关系。后续修改单个Landmark时，必须修改整个ModelData对象的数组，不仅效率低下，还无法利用SwiftData的增量更新、查询优化等核心特性。
  • 扩展性问题：这种方式违背了SwiftData的设计理念，后续添加模型关联、复杂查询逻辑会异常困难，维护成本极高。

总结 #

方案A是符合SwiftData设计逻辑的标准实现，扩展性和维护性更强；方案B虽能编译，但在数据操作性能和长期维护上存在致命问题，不推荐采用。

内容的提问来源于stack exchange，提问作者Nerdy Bunz