1

How to solve the problem of hundreds POCO Models without implementation of INotifyPropertyChanged and other WPF stuffs using the most efficient way to provide these functionality to WPF?

Right now I use EntityFramework with simple POCO classes and ViewModels written by hand.

My architecture looks like this:

  • View
  • ViewModel
  • Repository pattern
  • WCF repository or DB repository
  • Business logic
  • Entity Framework
  • POCO model classes

My thoughts about that are:

  1. Use Automapper to map POCO classes to ViewModels classes and before that create these ViewModels manually.
  2. Generate base ViewModels using T4 as a wrap on generated before POCO classes, write my own (or use existing solution) of Instance resolver class to provide the same functionality (one instance = one record in database) in EF.

I'm confused, because I don't like my own solution, it's not stable now, but Automapper use Reflection in mappings.

What to do? Do you know some fantastic, really great tool to do this magic things and gives me a flexibility to add and extend ViewModel?

Damianos88
  • 33
  • 7

1 Answers1

2

I believe you assume:

  1. usually you create copies of Model objects inside the ViewModel
  2. usually you implement INotifyPropertyChanged inside each object of your ViewModel

I believe both assumptions are wrong. Look at the following code sample:

class Customer
{
  public int ID {get; set;}
  public string Name {get; set;}
}

class MyViewModel: INotifyPropertyChanged
{
  // Hook you repository (model) anyway you like (Singletons, Dependency Injection, etc)
  // For this sample I'm just crating a new one
  MyRepository repo = new MyRepository();

  public List<Customer> Customers 
  {
    get { return repo.Customers;}
  }

  public void ReadCustomers()
  {
    repo.ReadCustomers();
    InternalPropertyChanged("Customers");
  }

  public event PropertyChangedEventHandler PropertyChanged;
  protected void InternalPropertyChanged(string name)
  {
    if (PropertyChanged != null)
      PropertyChanged(this, new PropertyChangedEventArgs(name));
  }
}

class MyRepository
{
  private List<Customer> customers;
  public List<Customer> Customers
  {
    get { return customers; }
  }

  public void ReadCustomers()
  {
    // db is the Entity Framework Context
    // In the real word I would use a separate DAL object
    customers = db.Customers.ToList();
  }
}

Customers is a List returned by the Entity Framework. The ViewModel property Customers is simple a passthrough property which points to the Model property.

In this sample I dont use INotifyPropertyChanged inside Customer. I know the Customers list can be modified only when the user call ReadCustomers(), so inside it I call PropertyChanged.

If I need to fire PropertyChanged notifications for the Customer class, I wuold implement INotifyPropertyChanged directly on the Customer class.

corradolab
  • 718
  • 3
  • 16
  • Probably you dont use INotifyPropertyChanged because you don't need it. But if I create WPF detail view for present model class or more complex data like two or more models I have to have ViewModel that represent (wrap) model data and provide WPF functionality for View purpose. – Damianos88 Feb 01 '15 at 17:18
  • As I wrote before, my model is simple POCO so there is a rule to not add anything else than data structure, maybe validation is allowed, but that's all. – Damianos88 Feb 01 '15 at 18:30
  • Change notification in the Model is allowed. See [SO](http://stackoverflow.com/questions/772214/in-mvvm-should-the-viewmodel-or-model-implement-inotifypropertychanged) and [MSDN](https://msdn.microsoft.com/en-us/library/gg405484(v=pandp.40).aspx). Change notification is not "GUI stuff" despite most of the time it's used to update the GUI. I still dont see the need to duplicate Model data over the ViewModel just to handle master detail or expose data coming from multiple Models. Would be curious to see an actual case. – corradolab Feb 01 '15 at 21:48
  • Yearh, you know, this is a requirement to my architecture so, I need to take care about WPF functionality only in Presentation layer. – Damianos88 Feb 02 '15 at 15:00
  • Ok, may be this is not I look for, but in fact this is a solution. Thanks – Damianos88 Feb 04 '15 at 07:31