WPF: MVVM & Editing Hierarchical Data

Question

I'm still trying to wrap my head around MVVM. Let's say I have a Model that looks something like this:

public class Company  
{  
    public IList<Division> Divisions { get;set;}  
}

public class Division  
{  
    public string Name { get;set;}
    public IList<Department> Departments { get;set}
}  

public class Department
{
    public string UnitNumber { get;set;}
    public string DepartmentName { get;set;}
    public IList<Employee> Employees { get;set;}
}

public class Employee
{
    public string FirstName { get;set;}
    public string LastName { get;set;}
    public string JobTitle { get;set;}
}

Now let's say I want to display the company hierarchy in a hierarchical grid, I create a CompanyViewModel class below:

public class CompanyViewModel : INotifyPropertyChanged
{
    private Company _company;
    public Company Company
    {
         get { return _company;}
         set { _company = value; NotifyPropertyChanged("Company");}
    }
}

Now on my view (WPF), I would set the data context to the ViewModel and the datagrid of choice would bind to the "Company" Path. Everything's great so far.... I get a nice expand/collapse interface into Divions, departments, employees...

Except:

1. What if the grid is editable... Department Names should be able to be changed (and validated by the ViewModel, same for Employee names..

2. What if I want to add new employees, departments, etc. all of that should be reflected in the grid without rebinding (that's the point of WPF databinding isn't it?)

Potential Solution:

You have a separate ViewModel class for every Domain class...

This seems to imply alot of mapping from DTO -> ViewModel, duplication (because they're almost the same objects and yet not exactly.) Given that I'm probably already mapping from some kind of ORM entity -> DTO on the service side, sending it over the wire (WCF) to the client, mapping every DTO hierarchy into its own ViewModel is a heavy, expensive process (not to mention the work involved in doing so.)

Bleeding things like INotifyPropertyChanged, ObservableCollection, etc into my DTOs seems like a hack.

Does anyone have a better solution? Am I crazy? ;-)

Answer 1

"Bleeding things like INotifyPropertyChanged, ObservableCollection, etc into my DTOs seems like a hack."

I feel your pain, but that is the approach I've taken on a couple of projects.

Bottom line: For WPF databinding to "work" as advertised the objects/collections you bind to need to support INotifyPropertyChanged and ObservableCollection.

Personally I think creating DTO's that support this is a LOT less work than constantly translating data back and forth into a viewmodel or other intermediate object that is essentially a richer version of the DTO object.

Answer 2

If you're getting sick of typing in code for INotifyPropertyChanged and you also use automatic properties, why not take a look at MoXAML Power Toys, which allows you to convert automatic properties into notifiable ones?