R – Silverlight MVVM: how to avoid polluting the model while still implementing “add new item” for the datagrid

data-bindingmvvmsilverlight

I have a DataGrid. Right now it's binding to an ObservableCollection<Foo> in my model just great.

But now I want to implement a user-friendly way to add a new item to the datagrid. It seems like I'll need to modify Foo to inherit from IEditableObject and INotifyPropertyChanged, which is kind of icky from a MVVM perspective in my mind—those seem more like view-type implementation details. But whatever, not as big a deal.

(Edit: clarification; Foo is in my model, not viewmodel.)

But now I know I'm doing something wrong when I have to change my ObservableCollection<Foo> into a custom CollectionOfFoo with logic for adding blank Foo items to the end of the collection whenever the user commits a change, like in the referenced blog post. That stuff definitely doesn't belong in my model.

How can I implement such a nice UI for adding new items, while at the same time preserving my MVVM-ness? I was thinking maybe some kind of wrapper around my collection that implements this, but I'm not sure how to make that wrapper bind back to the model… :-S.

Best Answer

That stuff definitely doesn't belong in my model.

But it definitely does belong in your viewmodel. And an observable collection of viewmodel classes is what your datagrid should be bound to.

It sounds to me like (if Foo is Model class) you need to write a FooViewModel class.

Another approach to this would be to add your "new" item in another control, maybe write a form and have it appear over the top of the datagrid whenever the user elects to create a new row?

Related Solutions

R – How to connect the ModelView to the Model in this Silverlight MVVM example

The way I use a ViewModel is somewhat different. In my case it actually wraps the Model class passing most of the data on to the model. That way all standard business rules in the model still work the way they are supposed to right away. The ViewModel only exposes those properties actually needed for data binding or other UI purposes. Additionally the ViewModel might contain other properties/methods used for data binding.

So using your customer example: namespace TestMvvm345 { public class CustomerViewModel : INotifyPropertyChanged {

    private Customer _model;
    public Customer Model
    {
        get
        { return _model; }
        set
        {
            if (_model != null)
                Model.PropertyChanged -= Model_PropertyChanged;

            _model = value;

            if (_model != null)
                Model.PropertyChanged += Model_PropertyChanged;
        }
    }

    void Model_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        RaisePropertyChanged(e.PropertyName);
        if (e.PropertyName == "FirstName" || e.PropertyName == "LastName")
            RaisePropertyChanged("FullName");
    }

    public string FirstName
    {
        get { return Model.FirstName; }
        set { Model.FirstName = value; }
    }

    public string LastName
    {
        get { return Model.LastName; }
        set { Model.LastName = value; }
    }

    public string FullName
    {
        get { return FirstName + " " + LastName; }
    }


    public static IList<CustomerViewModel> GetCustomers()
    {
        var result = new List<CustomerViewModel>();
        var customers = Customer.GetCustomers();
        foreach (var customer in customers)
        {
            result.Add(new CustomerViewModel() { Model = customer });
        }
        return result;
    }
    public event PropertyChangedEventHandler PropertyChanged;

    private void RaisePropertyChanged(string property)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(property));
        }
    }
}


public class Customer : INotifyPropertyChanged
{
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int NumberOfContracts { get; set; }

    public static List<Customer> GetCustomers()
    {
        List<Customer> customers = new List<Customer>();
        customers = new List<Customer>();
        customers.Add(new Customer { FirstName = "Jim", LastName = "Smith", NumberOfContracts = 23 });
        customers.Add(new Customer { FirstName = "Jane", LastName = "Smith", NumberOfContracts = 22 });
        customers.Add(new Customer { FirstName = "John", LastName = "Tester", NumberOfContracts = 33 });
        customers.Add(new Customer { FirstName = "Robert", LastName = "Smith", NumberOfContracts = 2 });
        customers.Add(new Customer { FirstName = "Hank", LastName = "Jobs", NumberOfContracts = 5 });
        return customers;
    }

    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    #endregion
}

}

Now in your UI you bind using the following code: customerHeaderView.DataContext = CustomerViewModel.GetCustomers();

The code in the ViewModel does become somewhat large but a lot can be put in a base class and all properties that go to the Model are exactly the same (think T4 template).

Related Topic