Prism MVVM架构中业务模型与视图模型分离的正确性验证

Absolutely, moving those properties into a standalone Person business model class is a fantastic, industry-standard practice that fits perfectly with MVVM principles and Prism's design philosophy. Here's why this approach is solid, plus some context to confirm your implementation:

Key Reasons This Is the Right Move #

• Separation of Concerns: Your ViewModel should focus on UI-related logic (commands, view state management) rather than holding raw business data. By isolating person-related properties in a Person class, you keep your code organized and each component focused on its core job.
• Reusability: A dedicated Person model can be reused across your application—whether in other ViewModels, data persistence services, or API integrations—instead of duplicating properties everywhere.
• Maintainability: If you ever need to add business rules (like name validation) or modify properties later, you only have to update the Person class, not every ViewModel that was holding those properties.

Example Implementation to Validate Your Code #

Assuming your Person class looks something like this (either as a plain POCO or using Prism's BindableBase for property change notifications), you're on the right track:

Option 1: Plain POCO (for static data or when UI updates aren't needed on property changes) #

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime LastUpdated { get; set; }
}

Option 2: BindableBase Implementation (for dynamic data that needs UI updates) #

If you want changes to Person properties to automatically reflect in the UI, inherit from Prism's BindableBase to leverage built-in INotifyPropertyChanged support:

using Prism.Mvvm;

public class Person : BindableBase
{
    private string _firstName;
    public string FirstName
    {
        get => _firstName;
        set => SetProperty(ref _firstName, value);
    }

    private string _lastName;
    public string LastName
    {
        get => _lastName;
        set => SetProperty(ref _lastName, value);
    }

    private DateTime _lastUpdated;
    public DateTime LastUpdated
    {
        get => _lastUpdated;
        set => SetProperty(ref _lastUpdated, value);
    }
}

Integrating with Your ViewModel #

In your ViewModel, expose an instance of Person instead of the individual properties:

public class YourViewModel : BindableBase
{
    private Person _currentPerson;
    public Person CurrentPerson
    {
        get => _currentPerson;
        set => SetProperty(ref _currentPerson, value);
    }

    public YourViewModel()
    {
        // Initialize with sample data or load from a service
        CurrentPerson = new Person
        {
            FirstName = "Jane",
            LastName = "Smith",
            LastUpdated = DateTime.Now
        };
    }
}

Adjusting Your XAML Binding #

Update your view bindings to reference the Person object's properties, like:

<TextBox Text="{Binding CurrentPerson.FirstName}" />
<TextBox Text="{Binding CurrentPerson.LastName}" />
<TextBlock Text="{Binding CurrentPerson.LastUpdated, StringFormat='Last Updated: {0:g}'}" />

Final Confirmation #

The original example you're working from likely kept properties directly in the ViewModel for simplicity (to keep the demo focused on Prism basics). Extracting them into a Person model is exactly how you'd structure a real-world Prism application—great job thinking ahead to scalable, maintainable code!

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