CODEWITHSUNDEEP
wpfmvvm
Flack
Flack

Reputation: 5889

Creating the Model part of MVVM

I am working on an app where I am trying to use MVVM for the first time. After reading some things, I think I might have misunderstood what goes in the Model.

All my app does right now is make a request to get some data, display it, allow the user to edit it, and save it if changes were made.

Here is an example of my current setup. I read some Employee data, which returns groups of employees ("Managers", "VPs", etc.). Each group contains a list of people. I created an interface to represent the groups:

public interface IEmployeeGroup : INotifyPropertyChanged
{
    bool IsDirty { get; set; }
    string GroupName { get; set; }
    ObservableCollection<IPerson> People { get; set; }
}



public interface IPerson : INotifyPropertyChanged
{
    bool IsDirty { get; set; }
    string PersonName { get; set; }
    int Id { get; set; }
}

I then create concrete EmployeeGroup and Person classes implementing those interfaces. And thats all they do, expose the specified properties.

That is all I have for my model.

My view model implements the below interface:

public interface IEmployeeGroupsViewModel
{
    ICommand AddEntryCommand { get; }
    ICommand SaveCommand { get; }

    ObservableCollection<IEmployeeGroup> EmployeeGroups { get; set; }
    ObservableCollection<IPerson> People { get; set; }
}

The view model makes the call to get the actual data, creates the EmployeeGroup and Person objects, and then returns them in properties for the view to bind to. When the user wants to save his changes, the view model makes the call to persist the changes.

Am I putting too much in my view model, which should be in the model instead? Right now my model does nothing, they are just the classes that represent the objects.

If I am off track here, can someone give me some advice? How would I change my above scenario for example?

Thank you.

Upvotes: 3

Views: 1397

Answers (2)

Robert Rossney
Robert Rossney

Reputation: 96702

That looks right to me.

I could be wrong, but I don't really see a benefit from making your view model interfaces derive from INotifyPropertyChanged. That seems like unnecessarily coupling together two things that don't really have any intrinsic relationship to one another. I'd just declare the PersonViewModel class (for instance) as:

public class PersonViewModel : IPerson, INotifyPropertyChanged

Upvotes: 0

Richard Szalay
Richard Szalay

Reputation: 84724

There's nothing wrong with your approach. You are free to either expose mapped model properties from your view model if they require formatting, or you can expose your model directly from your view model if no changes need to be made.

MVVM is about testability, not pattern purity. As long as what you are doing works, you can always refactor later.

Upvotes: 4

Related Questions