Passive MVVM

9 views
Skip to first unread message

CBl...@eki-consulting.com

unread,
Feb 5, 2010, 10:53:38 AM2/5/10
to wpf-di...@googlegroups.com
OK, time for me to dip my toe in the pool. When people ask me about MVVM I
usually send them towards MVVM Light but in my own code I have been writing
my own VMs using Prism for commanding. My view models are written in a very
passive style which I really like but I have been wondering what everyone
else things.

For example, a typical property in my view model might look like this:

private PagedCollectionView foos;
public IEnumerable<Foo> Foos
{
get
{
if (foos == null)
{
Context.Load(Context.GetFoos().Where(f => f.Filter ==
this.CurrentFilter));
foos = new PagedCollectionView(Context.Foos);
foos.Filter = FoosFilter;
}
}
set
{
foos = value;
RaisePropertyChanged("Foos");
}
}

When the CurrentFilter changes I just do a Foos = null. What I like about
this style is that the ViewModel is usually just reacting to what the View
asks for and not jumping ahead. If the View isn't binding Foos at the
moment then the PagedCollectionView isn't created and no data is loaded
from the server. Changing the CurrentFilter doesn't cause new data to load
from the server either, it just clears the foos PagedCollectionView and
raises the PropertyChanged event which, if the View is still bound, will
eventually cause new data to be loaded.

I find this style lends itself well to long lived ViewModels that are being
kept in an IoC container and ViewModels that are being shared by multiple
Views. However, is this a good general way to design ViewModels or are
there design problems with being so property driven that I haven't hit yet?

Daniel Vaughan

unread,
Feb 5, 2010, 11:07:06 AM2/5/10
to WPF Disciples
Hi Colin,

My main concern would be the risk of reducing UI responsiveness. I
would avoid stepping out to grab data from the UI thread. I would bind
to an Observable collection, and trigger the population some other
way.

Daniel Vaughan

unread,
Feb 5, 2010, 11:15:06 AM2/5/10
to WPF Disciples
Bea also has a nice post on async bindings, that could prove useful
with the approach you describe.

http://bea.stollnitz.com/blog/?p=27

On Feb 5, 4:53 pm, CBl...@EKI-CONSULTING.COM wrote:

Josh Smith

unread,
Feb 5, 2010, 11:32:48 AM2/5/10
to wpf-di...@googlegroups.com
I use a similar approach sometimes, but only when I am certain that the lazy-loading won't negatively impact UI responsiveness, as Daniel mentioned.  One solution to that problem is to have the Foos return an ObservableCollection<T> which is immediately returned and subsequently populated in the background.  Since observed collection changes must occur on the UI thread, one must be sure to marshal the .Add()s over to the UI thread.

Josh

Peter O'Hanlon

unread,
Feb 5, 2010, 11:39:00 AM2/5/10
to wpf-di...@googlegroups.com
I sometimes do this too, but I also use VM prioritisation to determine the sequence of loading of VMs when there's lazy loading involved.
--
Peter O'Hanlon

CBl...@eki-consulting.com

unread,
Feb 5, 2010, 12:42:28 PM2/5/10
to wpf-di...@googlegroups.com

Sorry, I forgot to underscore a few things. I am using Silverlight and WCF RIA Services. Context is the DomainContext and Context.Load is async. Unless there are already entities in the EntitySet which match the filter, the call to the Foos property is returning an empty PagedCollectionView. The PagedCollectionView will fill itself when the load completes and it is Observable.

Colin Blair


Daniel Vaughan <dbva...@gmail.com>
Sent by: wpf-di...@googlegroups.com

02/05/2010 08:07 AM PST


Please respond to wpf-di...@googlegroups.com


To  

WPF Disciples <wpf-di...@googlegroups.com>

cc  


bcc  


Subject  

[WPF Disciples] Re: Passive MVVM


Hi Colin,

My main concern would be the risk of reducing UI responsiveness. I
would avoid stepping out to grab data from the UI thread. I would bind
to an Observable collection, and trigger the population some other
way.


Reply all
Reply to author
Forward
0 new messages