MVVM架构数据序列化疑问：正确Model设计及ViewModel序列化误区解答

Great question—you’re already making solid progress by separating your Model and ViewModel, so let’s clarify the details and fix any rough edges in your implementation.

1. Is Your Current Model/ViewModel Implementation Correct? #

Your Model is Perfect #

Your ExampleModel is exactly what a Model should be in MVVM: a plain data carrier with no UI-related logic or property change notifications. It’s focused solely on holding the data you need to serialize, which makes it ideal for XML (or any) serialization.

Your ViewModel Has Redundant Code #

The private fields lowerRange and upperRange in your ViewModel are completely unnecessary—you’re already reading/writing directly to the underlying model instance. Those fields serve no purpose here and just add extra, unused code.

Here’s the cleaned-up, correct ViewModel:

public class ExampleViewModel : ViewModelBase { 
    private ExampleModel model; 

    public ExampleViewModel() { 
        model = new ExampleModel(); 
    } 

    public double LowerRange { 
        get { return model.LowerRange; } 
        set { 
            model.LowerRange = value; 
            RaisePropertyChanged(); 
        } 
    } 

    public double UpperRange { 
        get { return model.UpperRange; } 
        set { 
            model.UpperRange = value; 
            RaisePropertyChanged(); 
        } 
    } 

    // Bonus: Method to trigger serialization (only touches the Model)
    public string SerializeModel() {
        // Use your XML serializer of choice here
        var serializer = new XmlSerializer(typeof(ExampleModel));
        using var writer = new StringWriter();
        serializer.Serialize(writer, model);
        return writer.ToString();
    }
}

2. Should a Model Use RaisePropertyChanged()? #

Short answer: No, never.

MVVM relies on strict separation of responsibilities:

• Model: Handles data storage, business rules, and data validation (e.g., ensuring LowerRange doesn’t exceed UpperRange). It should have zero knowledge of the UI or property change notifications.
• ViewModel: Acts as the bridge between the View and Model. It exposes Model data to the View, handles UI-specific logic, and uses RaisePropertyChanged() to notify the View of updates.

If you add RaisePropertyChanged() to your Model, you’re mixing UI concerns into your data layer. This turns your Model into a hybrid "Model-ViewModel" that violates the single responsibility principle—now it’s responsible for both data and UI notifications, which makes it harder to maintain, test, and reuse.

A Complete Example with Business Logic #

To make this concrete, here’s an expanded example where the Model handles business validation, and the ViewModel manages UI feedback:

Model (Pure Data + Business Logic) #

public class ExampleModel { 
    public double LowerRange { get; set; } 
    public double UpperRange { get; set; } 

    // Business rule: LowerRange can't be greater than UpperRange
    public bool IsValid() {
        return LowerRange <= UpperRange;
    }
}

ViewModel (UI Bridge + Notifications) #

public class ExampleViewModel : ViewModelBase { 
    private ExampleModel model; 
    private string validationMessage;

    public ExampleViewModel() { 
        model = new ExampleModel(); 
    } 

    public double LowerRange { 
        get { return model.LowerRange; } 
        set { 
            model.LowerRange = value; 
            RaisePropertyChanged(); 
            ValidateModel();
        } 
    } 

    public double UpperRange { 
        get { return model.UpperRange; } 
        set { 
            model.UpperRange = value; 
            RaisePropertyChanged(); 
            ValidateModel();
        } 
    } 

    public string ValidationMessage {
        get => validationMessage;
        set {
            validationMessage = value;
            RaisePropertyChanged();
        }
    }

    private void ValidateModel() {
        if (model.IsValid()) {
            ValidationMessage = "Range is valid";
        } else {
            ValidationMessage = "Error: Lower range cannot exceed upper range";
        }
    }

    // Serialize only the Model
    public string SerializeToXml() {
        if (!model.IsValid()) {
            throw new InvalidOperationException("Cannot serialize invalid model");
        }

        var serializer = new XmlSerializer(typeof(ExampleModel));
        using var writer = new StringWriter();
        serializer.Serialize(writer, model);
        return writer.ToString();
    }
}

Key Takeaways #

• Always serialize the Model, not the ViewModel. The ViewModel is a UI adapter—its job is to make the Model work with the View, not to hold the core data you need to persist.
• Model = Data + Business Logic: No UI code, no property change notifications.
• ViewModel = UI Logic + Notifications: Holds a reference to the Model, exposes its data to the View, and handles UI-specific tasks like validation feedback.

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