Does 1 ViewModel really have 1 View?

its said that 1 ViewModel has 1 View.

1 View is for me a UserControl. What if my UserContr开发者_JS百科ol has different areas filled with data from different entities, do I have then several Views and need to build several ViewModels?

e.g: I display in a UserControl 3 entities: customer(listbox),order(datagrid),product(datagrid). Each of those "data areas" has add+remove buttons and textboxes to enter data.

Actually each of those "data areas" are put in its own GRID having so the posibility to set a individual datacontext.

1.) Should I now create 3 ViewModels CustomerVM,OrderVM and ProductVM? 2.) Are those 3 "data areas" seen as an own sort of separated View, although I have not put them in 3 UserControls.xaml files ??? 3.) When this one UserControl is inside a TabControl`s tabpage where do I load the 3 entities related data? Inside the MainViewModel? I want to show/load that data only when the user clicks the tabheader.

No, you can do all that in the one viewmodel. The job of the viewmodel is to hold the data for the view, and if necessary transform that data so the view can consume it. There is nothing that says a viewmodel has to hold specific types of information, i.e. there are no rules that state "it may only hold customer info and not order info".

Having said that, there is also no reason why the viewmodel cannot be consumed by several different views (give them all different instances, of course) - this would show that you have a good separation of concerns between your views and viewmodel. Personally, i code my viewmodels so that they have no idea that the view exists. There is also no reason why the view has to consume everything that the viewmodel exposes, although binding a CustomerView to a CustomerOrderProductViewModel is going a little too far.

Edit: let me explain that last paragraph a little more.

Example 1: i have a new V which shows customer information, and i have an existing VM which has customer info AND order info

I would be reluctant to use this VM for this V, because while it does have the client info i need, it has too much info - i'm using the VM out of the context is was originally intended for.

Example 2: i have a VM that contains full client info, like their postal and residential address, their phone numbers, their girlfriend's names*, and a bunch of other client type info. I have a V which shows the client's name, birthday, and maybe two other properties.

I would consider using that VM for that V, this illustrates my point that the V doesn't have to show all the info contained within the VM. This concept becomes more apparent when you change the V (as in, do some maintenance and change the UI of the view, because someone has decided that they want a bunch of fields removed and now they want to represent the client's age as an image) - i can still use the same VM, and just change the V (i could use a ValueConverter to represent the age as an image, thus avoiding a change to the VM).

At what point would i stop using the current ClientViewModel, and write a new one that was more specific to the needs of the modified ClientView?

There is no clear cut answer to that - it depends on the amount of time i have available to do the changes, the amount of time available for testing, and the trade-off in complexity between using a full blown Client object for the VM, and writing a new leaner version of the Client object while still retaining the old one.

*that should be a collection of independant objects incorporated in the client object, but just work with me here it's a made up example :)