Reflection on our MVVM implementation

We are refactoring existing framework to use MVVM these days. Everything worked out greatly and so far we have not found the need to check what third-party MVVM libraries would provide.

There were several things that I feel it's worth to write down for this work:

• Who's creating the objects. ViewModel was supposed to do that. We use XML to define dataset definitions like where to get data and how to save data. We create ViewModel inside the View (XAML), and it's a different stage where the data would be created. So I created a service controller class which is dedicated for creating the data. We later injected the data into the ViewModel.
• One or more data models. We have a lot of grids in the view (that's very common in business apps). It's very natural to model grid row data into a data model (i.e., an object class). However, there might be other models you want to model in the view... . Originally I created a model list to hold all possible data models for the view, I mean the data models on view level (not the row level). It looked good to me, but not to others when I explained to them. So I decided to make things simple -- all other properties that I want the View to bind to would be defined in the ViewModel, without introducing view level data models.
• Issue on child collection. We all know that we use ObservableCollection for list of child objects, e.g. if our data model is class A, it contains ObservableCollection<T> ChildB. The question is do I need to fire property changed for ChildB itself (not the items inside ChildB)? That's still not clear and it seems to be working without doing that.