WPF MVVM modeling using Entity Framework CTP5 Code First

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

Question

Here is an example model class: I have my model set up and functioning for my WPF application using entity framework ctp5 code.

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; }
}

How should I construct my view model, in your opinion? To make the model classes readily reusable in different projects, my view models will implement INotifyPropertyChanged. I do not want the model classes to include any UI-specific functionality. Should I virtualize every model property before overriding it in the view model? (Appears to have a lot of pointless code...) Would this kind of format work well with EF code first?

Edit Similar to question Which should implement INotifyPropertyChanged in MVVM: the ViewModel or the Model?, but with just one apparent solution—integrating what I would call UI logic into the model. Maybe I can add a delegate to the model and hook into it from the viewmodel, which will then utilize something like INotifyPropertyChanged?

    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

Making an instance of my model class and assigning it to a ViewModel property is what I'm doing.INotifyPropertyChanged directly on the model for the characteristics of the model, and simply on the viewmodel for the instance of the model, as follows:

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
}

I then attach straight to Model properties in XAML, for example:

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

The DataContext for the View would be the TaskViewModel in this case.

I only do this because of the "amount of superfluous code" you describe, and I was unable to see any disadvantages. (I use EF Code-First to make my model permanent.)

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

Popular Answer

Although I am aware that this discussion is old, I came upon this blog when searching for information on the subject. Article from msdn.com: zzz-5 zzz

In essence, the CodeFirst dbSet object now has a new attribute as of CTP 4 of EF CodeFirst. Local. . INotifyPropertyChanged is an ObservableCollection that implements Local. Therefore, you may set your forms' data context to Tasks if your code initial database context exposes a DbSet(Of Task) named 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