View Model Anyone?

View Model Anyone?

Old forum URL: forums.lhotka.net/forums/t/8039.aspx

kevnworking posted on Tuesday, November 24, 2009

Hey All,

Disclaimer: I'm new to the view model concept, never used it before but have need for it now.

When creating a view model for the collection, how else can I associate the business object with the view model besides using DoRefresh?  The real issue I have is trying to figure out how I can create a view model for a collection/BO that is the child of another object.  The DoRefresh method wants the factory method of the collection, which of course used to reside in the property declaration and DataPortal_Fetch method of the parent object.

So how can I create a view model but still have the child object associated with it's parent?

See where I am struggling?  If someone could point me to an example I would be most appreciative.  I have studied Lhotka's view model example but this type of scenario is not covered near as I can tell...  I only need a view model for this one child collection.

Happy Thanksgiving!

Kevin

RockfordLhotka replied on Tuesday, November 24, 2009

There are different interpretations of MVVM - some work better with anemic models and some with rich models.

CSLA .NET helps you create rich models.

If you have an anemic model, you may need to wrap every object with a viewmodel. That's a lot of work, because it means you need to create a viewmodel object graph that mirrors the shape of the model and then you must keep them in sync. It is a real pain.

Fortunately CSLA helps you create a rich model, so you shouldn't have to go through nearly so much pain.

When creating a viewmodel for a rich model, the shape of the viewmodel should be determined more by the view than the model. I tend to create a viewmodel for each logical region or section on my form. So I'll usually have one viewmodel for the entire form, which wraps the root object from the model. Then if I have a region of the form where I show a list of child objects, I might have a viewmodel for that region of the form, wrapping the child collection.

To make that easy, the ViewModelBase class exposes a Model property that is bindable. In other words, you can chain the viewmodel objects, so your child viewmodel binds to the appropriate property of the parent viewmodel (or model).

This is illustrated in the MVVMexperiment project, though the child isn't a collection, it is a single object. But the concept is exactly the same.

kevnworking replied on Tuesday, November 24, 2009

Hey Rocky!  Thanks for the quick reply.

I understand ALMOST everything you told me - wrap the parent class in a view model and that will give me the ability to create another view model for one of it's child collections.  I hadn't thought of exposing the child collections that way.

Here is where I'm still a bit fuzzy - you said:
you can chain the viewmodel objects, so your child viewmodel binds to the appropriate property of the parent viewmodel (or model)

Could you expand a bit on this statement?  It seems like you are saying that I could wrap the child collection object in a view model via the child collection object's exposure through the model property of the parent view model.

I guess I'm confused as to what the child collection view model's constructor would look like.  Basically, how the child collection view model would be "loaded".

Thanks again for helping me understand this!

Kevin

RockfordLhotka replied on Tuesday, November 24, 2009

You don’t really need a constructor. The idea is to set the Model property of the child viewmodel from a property on the parent model – purely through XAML.

 

<this:ParentViewModel x:Key=”RootVM”/>

<this:ChildViewModel x:Key=”ChildVM” Model=”{Binding Source={StaticResource RootVM},Path=Model.ChildList}”/>

 

The ParentViewModel would typically have a ctor where you load its Model with something valid. But the ChildViewModel gets its Model property set through binding.

 

kevnworking replied on Tuesday, December 29, 2009

I have been away from this project a while but am now back on it - I was able to get the view model's working (thanks Rocky!).

My "Save" and "Cancel" buttons were not working and I realized it's because I still have them bound to the CSLA Data Provider that no longer exists.  Because my root object is now wrapped in a view model class, what is the best way to handle the save and undo?  Should I mimic the way the buttons work in a Windows forms example?

Thanks,

Kevin

RockfordLhotka replied on Tuesday, December 29, 2009

The ViewModelBase (and therefore ViewModel) class implements a number of public properties like CanSave, CanCancel, etc. You can bind to those to control most buttons or similar UI action elements.

Copyright (c) Marimer LLC