When ONE View has ONE ViewModel then a Customer-Order-Product relation/gui can get very nasty

I think I got some sort of knowledge flash and now I am totally confused. I looked at many mvvm implementations like Ocean,Stuff,BBQShack,MVVM demo,WAF,Chinch1,2 etc...

Everyone is doing MVVM differently somehow...

There is ONE scenario that drives me nuts. I am missing understanding and I hope someone can clear the clouds in my head.

But before I want to post a comment from Jeremy Likness:

" I believe most developers agree that a view should have exactly one viewmodel. There is no need to attach multiple viewmodels to a single view. If you think about separation of concerns, this makes sense, because if you have a "contact widget" on the screen bound to a "contact viewmodel" and a "company widget" bound to a "company viewmodel", these should be separate views, not a single view with two viewmodels."

Scenario: When a View has ONE ViewModel or a ViewModel is bound to ONE UserControl...

Question: Do I need to create 开发者_JS百科3 UserControls CustomerView, OrderView, ProductView for each ViewModel ? If so how do you synchronize the databinding in the GUI between the 3 UserControls with the 3 ViewModels in the background? Using a Messaging System?

If your answer is YES, then why should I not create ONE big UserControl bound to BillingViewModel acting as Controller which exposes the property ObservableCollection CustomerListWithAllOrdersAndProducts which can easily be bound to the top control`s datacontext and all 3 Grids(customer etc...) below it bind to the current datacontext. Then the changing of the customer would automatically change the orders and products ...

How would you handle this scenario when there are not only 3 UserControls like DataGrids in a Screen but there is also Customer formular with 5 textboxes and a Order formular with 3 textboxes, would you put those formulars in further 2 UserControls so you have 5 UserControls in the Window and all together are "mapped" by its ViewModel communicating with a Messenger system. That can get very confusing... Is it really this way they do it in big mvvm apps?

You are suggesting that you need to create 3 controls (Customer/Order/Product) because your design requires you to do so. So that means your GUI designer can't choose to interleave customer fields with Order or Product fields.

Now this may or may not be a good idea... But I think it is a weird restriction. (It kind of implies you can't repeat the customer adress together with the order confirmation because it is in a different table).

It just isn't as simple that one of these MVVM design flavors is more correct than others. I reccomend that you review the alternatives and choose the MVVM flavor that helps you to solve your problem. And this 1:1 dogma does not appear to help you, so I'd ditch it.