Question

A domain model collection (normally a List or IEnumerable) is delegated to a ViewModel.

Thats means my CustomerViewModel has a order collection of type List or IEnumerable.

No change in the list is recognized by the bound control. But with ObservableCollection it is.

This is a problem in the MVVM design pattern.

How do you cope with it?

UPDATE: Sample of how I do it:

 public class SchoolclassViewModel : ViewModelBase
{
    private Schoolclass _schoolclass;
    private ObservableCollection<PupilViewModel> _pupils = new ObservableCollection<PupilViewModel>();        

    public SchoolclassViewModel(Schoolclass schoolclass)
    {
        _schoolclass = schoolclass;
        _schoolclass.Pupils = new List<Pupil>();

        foreach (var p in schoolclass.Pupils)           
            Pupils.Add(new PupilViewModel(p));            
    }

    public Schoolclass GetSchoolclass 
    {
        get { return _schoolclass; } 
    }

    public int ID { get; set; }       

    public string SchoolclassName
    {
        get { return _schoolclass.SchoolclassName;}
        set
        { 
            if(_schoolclass.SchoolclassName != value)
            {                    
                _schoolclass.SchoolclassName = value;
                this.RaisePropertyChanged("SchoolclassName");
            }

        }
    }   

    public ObservableCollection<PupilViewModel> Pupils
    {
        get{ return _pupils;}
        set
        {
            _pupils = value;
            this.RaisePropertyChanged("Pupils");
        } 
    }
}

Answer 1

Ok, I’ll go ahead and add my thoughts as an answer instead of in the comments. 🙂

I think the bottom line is that this is just the reality of the way WPF and databinding work. In order for two-way databinding to operate, collections need a means of notifying controls that are bound to them, and the standard lists and collections used in most domain objects don’t/won’t/shouldn’t support this. As I mentioned in a comment, being required to implement INotifyPropertyChanged for non-collection properties is another requirement that may not be met by a standard domain object.

Domain objects are not intended to to be viewmodels, and for this reason you may find that you need to map back and forth between the two types of objects. This is not dissimilar to having to map back and forth between domain objects and data access objects. Each type of object has a different function in the system, and each should be specifically designed to support their own role in the system.

All that said, Agies’s idea of using AOP to automatically generate proxy classes is very interesting, and something I intend to look into.