tags:

views:

220

answers:

1

Hi

I'm fairly new to mvvm and I have several questions :

is model = business layer?

if i have a customer model that contains list of orders and list or orders each contains list of items, how would you separate this in a view? At the moment, my CustomerModel have a CustomerViewModel. CustomerViewModel contains list of OrderViewModel. OrderViewModel contains list of ItemsViewModel. So if I retrieve an existing customer from the data layer for example, I would then create the appropiate OrderViewModel and ItemViewModel based on the existing list. Is this how you usually implement mvvm? Honestly, the whole 'rewrapping object' doesnt really feels right.

My customerview contains list of orders and items, each represented by its own user control and repeated using ItemsControl. each item has its own add, edit and delete button. I want to have some sort of modal dialog that is disabling the current tab (not the whole app) while user presented with appropiate form. The easiest solution that I found was by sort of creating a content control that have a control dp (named Control) that you can set and automatically create the rectangle overlay when isVisible = true. Control then binded to CustomerViewModel's dialogControl property.... I dont see this as a proper mvvm solution as I seems to be muddling the viewmodel with view. I think the more proper way would be having a viewmodel in the customerviewmodel that represent what the dialog contains and provide a template for that in each viewmodel.... but i dont seems to be able to think a way to implement the rectangle overlay with this solution.

Thanks!

A: 

I've been wrangling with this idea too. It seems like you have to repeat yourself between the Model and the ViewModel. The main reason for this is that the Model tends to be a traditional object, and a ViewModel implements INotifyPropertyChanged. To me, this is the difference - a ViewModel supports bi-directional binding.

Once I thought of it that way, then the Model becomes optional. In my case, the Model is usually some library code that I bring in, or a generated data access layer. Or to put it another way, the ViewModel contains the functionality, and the Model is the backing store.

I have even stopped calling my ViewModel classes xxxViewModel or xxxVM. Now they're just xxx. However, they all implement from IViewModel, which itself just inherits from INotifyPropertyChanged.

As far as your use of User Controls goes, I have been able to get away with using only DataTemplates for my Views. In the case of your tabs, the tab's ViewModel should launch the modal dialog, and at the same time should set an Enabled property to false while the dialog is open. Your tab View should disable itself when it sees the Enabled property is false.

Scott Whitlock
I agree with your definition and the distinctions between ViewModel and Model but what do you do for properties maintained at the Model level that need to be exposed through binding? Can the Model layer implement INotifyPropertyChanged and if not, how would you get a property on the Model to bubble changes up to the View?
ScottCher
@ScottCher: It's really an architectural issue. There simply is no way to automatically bubble all changes to a plain-old-object up to the ViewModel that wraps it, unless you define events to do that. In my case, I'm using immutable model objects, so I don't have that problem. ;)
Scott Whitlock