WPF MVVM modeling using Entity Framework CTP5 Code First

code-first ef-code-first entity-framework mvvm wpf

Question

I have my model all setup for my WPF application and working with entity framework ctp5 code first, here's a sample model class:

public class Task
{
    public int ID { get; set; }
    public int Index { get; set; }
    public string Content { get; set; }
    public int Indentation { get; set; }
    public DateTime Start { get; set; }
    public decimal Effort { get; set; }
    public decimal CompletedEffort { get; set; }
    public decimal Cost { get; set; }
}

What would be the recommended way to build my view model? My view models will implement INotifyPropertyChanged, I do not want the model classes to have any UI specific code - so that they can be easily reused in other apps. Should I make all of the model properties virtual then override them in the view model? (seems like a lot of unnecessary coding...) Would EF code first play nice with this type of format?

Edit This is a somewhat similar question In MVVM should the ViewModel or Model implement INotifyPropertyChanged? however, the only solutions appear to be adding in what I consider to be UI logic into the model. Perhaps I can add some sort of delegate to the model and hook into that from the viewmodel, which will in turn use INotifyPropertyChanged... something like this?

    public class Task
    {
        public delegate void HandleChange(string propertyName);
        public HandleChange ChangeHandler;

        public int ID 
        { 
            get
            {
                return ID;
            } 
            set
            {
                if(ID != value)
                {
                    ID = value;
                    ChangeHandler("ID");
                }
            }
        }
...
1
5
5/23/2017 10:31:00 AM

Accepted Answer

What I am doing is to make an instance of my model class to a property in the ViewModel and then implement INotifyPropertyChanged directly on the Model for the Model properties and on the ViewModel only for the Model instance, like so:

public class Task : INotifyPropertyChanged
{
    // Implementation of INotifyPropertyChanged
    // Raising the PropertyChanged event in the Setters of all properties
}

public class TaskViewModel : INotifyPropertyChanged
{
    private Task _task;
    public Task Task
    {
        get
        {
            return _task;
        }
        set
        {
            if (_task != value)
            {
                _task = value;
                RaisePropertyChanged("Task");
            }
        }
    }

    // INotifyPropertyChanged implementation
}

Then in XAML I bind directly to Model properties, for instance:

<TextBox Text="{Binding Task.Content}" />

(TaskViewModel would be here the DataContext for the View.)

I do this mainly to avoid this "lot of unnecessary coding" that you mention, and I could not find a drawback. (I make my model persistent with EF Code-First too.)

4
2/21/2011 6:00:00 PM

Popular Answer

I know this is an old thread, but I was googling about this very topic and stumbled upon this blogs.msdn.com article: http://bit.ly/iE3KHI

In short, starting with CTP 4 of EF CodeFirst there is a new property of the CodeFirst dbSet object .Local. .Local is an ObservableCollection that implements INotifyPropertyChanged. So if you have a code first dbcontext that exposes a DbSet(Of Task) called Tasks you can set your forms data context to Tasks.Local.



Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow