首次基于CoreData实现MVVM架构的多Tab数据问题及架构咨询

Hey Kristian! Let's tackle your CoreData and MVVM setup questions step by step—this is a super common scenario when building tabbed apps with CoreData, so you're not alone here.

Fixing Unsaved Changes Showing in the View Tab #

The root issue here is that you're using a single NSManagedObjectContext for both tabs. Since NSManagedObject instances are live-bound to their context, any changes you make (even unsaved ones) are immediately visible to all parts of your app using that same context. Here are two solid approaches to fix this:

Option 1: Use Parent-Child Managed Object Contexts #

This is a classic CoreData pattern for this exact use case:

• Keep your main context (used by the view tab) tied to the main thread, responsible for fetching and displaying saved data.
• Create a private child context for the edit tab. All edits happen in this child context—since it's a separate context, changes won't propagate to the parent (main) context until you explicitly save the child.
• When the user taps "Save":
  1. Save the child context first. This pushes changes up to the parent main context.
  2. Then save the main context to persist to disk (if needed).
  3. If you need to sync with a server, do that after saving the main context—only then will the view tab see the updated data.
• If the user cancels or switches tabs without saving, just discard the child context (or roll back its changes) and the main context stays clean.

Option 2: Use a "Draft" DTO Instead of Directly Editing the NSManagedObject #

Instead of binding your edit form directly to the NSManagedObject, create a plain Swift/Objective-C object (a Data Transfer Object, or DTO) that mirrors the user's properties. For example:

struct UserDraft {
    var name: String
    var email: String
    // mirror all your CoreData User entity properties
}

• When the edit tab loads, populate the UserDraft with values from the CoreData User object.
• Let the user edit the draft object—since this isn't tied to any CoreData context, changes won't affect the view tab's data.
• On save:
  1. Update the CoreData User object with the draft's values.
  2. Save the main context (and sync with the server).
• If the user cancels, just discard the draft—no CoreData changes to roll back.

Is Using CoreData Models Directly in View Controllers a Best Practice? #

Short answer: No, it's generally not recommended. Here's why:

1. Tight coupling: NSManagedObject instances are tightly bound to their managed object context and CoreData stack. If your VC depends directly on them, it becomes harder to test (you have to spin up a full CoreData stack for unit tests) and harder to refactor if you ever switch data layers.
2. Presentation logic pollution: VCs often need to transform data for display (e.g., formatting a Date into a user-friendly string, converting an enum to a localized label). If you use the NSManagedObject directly, you might end up putting this logic in the VC (making it bloated) or in the NSManagedObject subclass (violating its single responsibility of managing data persistence).
3. Lifecycle risks: NSManagedObject can become a "fault" if the context is reset or the object is deleted, which can cause crashes if your VC is still holding a reference to it.

Instead, your MVVM ViewModel should act as a middle layer: fetch the CoreData objects, map them to plain DTOs or ViewModel-specific models, and pass those to the VC. This keeps your VC focused on presentation, your ViewModel focused on business logic, and your CoreData layer focused on persistence.

Should You Use Multiple NSManagedObjectContexts to Solve the Original Problem? #

Absolutely—this is a valid and widely used solution. But it's not the only one (as we saw with the draft DTO approach). Which one you choose depends on your needs:

• Use parent-child contexts if you want to leverage CoreData's built-in change tracking and undo/redo support for edits. This is great if your edit flow is complex and you need to handle partial saves or undo actions.
• Use a draft DTO if you want a simpler, more lightweight approach that decouples your edit flow from CoreData entirely. This is easier to test and avoids any context-related complexity.

Either way, the key is to separate the editing state from the persisted state until the user explicitly confirms the changes.

内容的提问来源于stack exchange，提问作者Kristian Ray