Implementing NotifyPropertyChange on EF Generated Models to achieve TwoWay binding

Question

My goal is to do TwoWay binding off a generated EntityFramework model. What is the best way to implement NotifyPropertyChanged on properties in a generated entity model? For example, suppose I have this entity from a database:

public partial class Survey
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public bool Answer { get; set; }
}

I then create a ViewModel...

public class SurveyViewModel : ViewModelBase
{
    private Survey _survey = new Survey();
    public Survey
    {
        get { return _survey; }
        set
        {
            _survey = value;
        }
    }
}

How could I achieve 2 way binding other than writing dependency properties for every single property in the entity model, like so...

//below the declaration of the Survey entity in the viewmodel
public string FirstName
{
    get { return Survey.FirstName; }
    set
    {
        Survey.FirstName = value;
        NotifyPropertyChanged("FirstName");
    }
}
//This works but is very time consuming for large models

Let me know if I'm attempting this wrong...

Your DTO is normally not your Model, but there are lots of questions for this already. http://stackoverflow.com/questions/18835827/how-to-implement-inotifypropertychanged-on-entity-framework-entity http://stackoverflow.com/questions/14132349/implement-inotifypropertychanged-on-generated-entity-framework-classes Actually, what you are looking for is AutoMapper. You should be mapping your Model to your DTO and vice versa when you need to communicate with the DB. — TyCobb, Sep 25 '14 at 01:06

Jason Fry · Answer 1 · 2014-09-25T01:54:42.450

0

PropertyChanged.Fody may be what you are looking for:

// Non-auto generated partial class declaration

[ImplementPropertyChanged]
public partial class Survey
{

}

edited Sep 25 '14 at 01:54

answered Sep 25 '14 at 01:37

Jason Fry

1,204
12
24

score 0 · Answer 2 · edited May 23 '17 at 10:26

As commented by TyCobb, this question has been asked repeatedly and the result remains the same... here is a summary.

While there are ways pollute your data models with UI accommodating features such as INotifyPropertyChanged, the MVVM mantra teaches us that it is the View-Model's job to interact with the UI and the Data-Model should remain as pure as possible (POCO).

So what? How do we keep to MVVM but avoid the boiler-plate codes of exposing individual properties on the View-Model?

From experience, calling a RaisePropertyChanged is not reserved only for property setters but could be used to manually raise a property changed for a model that has had its own properties modified, thus, cause the UI to update.

Here is a code example...

public class SurveyViewModel : INotifyPropertyChanged
{
    private Survey _survey;

    public Survey Survey
    {
        get { return _survey; }
        set
        {
            _survey = value;
            RaisePropertyChanged(() => Survey);
        }
    }

    public void ModifySurvey()
    {
        // Modify a property of the model.
        Survey.FirstName = "Modified";
        // Make other modifications here...

        // Notify property changed
        RaisePropertyChanged(() => Survey);
    }
}

Implementing NotifyPropertyChange on EF Generated Models to achieve TwoWay binding

2 Answers2