Meaning of POCO classes in MVVM and Entity Framework

Question

I am trying to understand how WPF binding works in junction with MVVM and Entity Framework. So far I understand databinding as a concept related to properties. However, when it gets to EF I lose understanding of which objects to use to define the Model for database. For instance, I have a Model class for a Category:

 public class Category : INotifyPropertyChanged
    {
        string _CategoryId;
        public string CategoryId
        {
            get
            {
                return _CategoryId;
            }
            set
            {
                if (_CategoryId != value)
                {
                    _CategoryId = value;
                    RaisePropertyChanged("CategoryId");
                }
            }
        }

        string _CategoryName;
        public string CategoryName
        {
            get
            {
                return _CategoryName;
            }
            set
            {
                if (_CategoryName != value)
                {
                    _CategoryName = value;
                    RaisePropertyChanged("CategoryName");
                }
            }
        }


        /// <summary>
        /// 
        /// </summary>
        /// <param name="prop"></param>
        void RaisePropertyChanged(string prop)
        {
            if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(prop)); }
        }
        public event PropertyChangedEventHandler PropertyChanged;

    }

and POCO version:

public class CategoryPoco
{
    public CategoryPoco() { }

    public int CategoryId { get; set; }
    public string CategoryName { get; set; }
}

Properties of the non Poco class in my understanding can be then used in databinding. However, I also need to build the database context model:

public DbSet<Category> Categories { get; set; }

Now here is where I lose my understanding, do I use Poco or non-Poco classes when building the context model?

How do I match the two classes when I start exchanging data with the Database?

EF doesn't care if your data model implements INPC. In fact, nobody does. So let it implement INPC and use it throughout your application, from binding to database. — , May 08 '15 at 17:01

score 1 · Accepted Answer · edited May 23 '17 at 12:14

You use the "POCO version" to build the context model for your database. If you will, POCO is just defined as

Plain Old CLR Object. Just a normal class, no attributes describing infrastructure concerns or other responsibilities that your domain objects shouldn't have.

so technically, your Category is also considered as POCO. POCO doesn't have a different meaning when used with MVVM or EF. EF just uses those objects to map it back to the database.

In your Category class, I normally don't create another Model class just to have that INotifyPropertyChanged. It's more flexible and clear that your Category class should be called CategoryViewModel.

If I read your code and I see an INotifyPropertyChanged interface where WPF uses it also for DataBinding, then I would be against it as you are now using Model -> View pattern without the ViewModel as your middleman. (Assuming you use category as your binding source)

If you decided that you need to extend Category class, then I would suggest to use T4 template to generate your POCO Classes as a partial class, and create another partial class that implements INotifyPropertyChanged or add more properties that are not in the columns of a given table e.g., CategoryStatus, CategoryDescription and mark those properties with [NotMapped] attribute.

That way you don't have to do matching between the two classes and mostly your Model is already setup in the ViewModel to communicate it back with EF. You also have the flexibility to add more functionality to the object, which complies with the Open-Closed design principle.

I used to think that ViewModel is more related to the specific View. So technically you are saying that my POCO version of Category class can be eliminated and the model should be built from the normal class? — eYe, May 08 '15 at 16:02
It is related to a specific view. Always 1-1. Your model can be built from a `Factory` class, it's another design pattern. If you are using code first in EF, then whatever you object type that you set up that you want to map to a `Table`. In your given example code, it looks like `Category` is the type that is mapped back to the ORM. So yes, you can eliminate the Poco class. — 123 456 789 0, May 08 '15 at 16:10

Meaning of POCO classes in MVVM and Entity Framework

1 Answers1