Design Advice - Filtered Conductor Items

Apr 29, 2011 at 5:16 AM
Edited Apr 29, 2011 at 5:17 AM

My application consists of several views that provide filtered subsets of basically the same data and I'm looking for some advice as I try to implement CM for the first time.  A simple analogy for my scenario would be that my app shows PeopleData through PeopleViewModels but I filter the subset of master data based on a simple hierarchy . 

I have:

PeopleInfoViewModel : Screen

PeopleInfoListViewModel : Conductor<PeopleInfoViewModel>.Collection.OneActive

which I need to use over and over again.

I also have a CommunityViewModel, CityViewModel, StateViewModel, CountryViewModel.  Essentially hiearchies that each have some unique properties and screens but all use the same PeopleInfoListView to show the formatted readonly filtered list of People.  I have a single list in my application that I continually update and merge more data into as the user jumps to various levels. ie) Two cities should show a different set of people but the state view will show both sets and others.

What I am trying to do is find the most efficient way to manage this with all the built in caching etc. so that I don't have duplicates.  If the user opens the Community screen they will retrieve and view say 10 people.  If they then jump to the State screen I might load 120 people from the DB, add 110 new PeopleViewModels and refresh the underlying data for the 10 that already existed.

My big question is how that works with the Conductor on the PeopleInfoListViewModel out of the box and if I should be changing it.  Do I need to worry if I create a new PeopleInfoListViewModel for each level of the heirarchy I browse to and what is the best way to 'refresh' the conductor.Items as I open and then activate/deactivate.  I could have from 5-1000+ PeopleInfoViewModels depending on my screen.

I have upwards of 6 or 7 business objects that I need to handle like this and some of them will have more complicated ViewModels so I don't want to be destroying/creating them endlessly for each new UI View.

Should I try to be fancy and filter at the items level or try to make my UI control filter the Items?  I feel like I have so many 'lists' I don't want to be filtering endless times.

I have ApplicationList<PeopleInfoBO>, ApplicationList<PeopleInfoViewModel>, CityViewModel.Conductor<PeopleInfoViewModel> for City A, for City B.

In all likelihood I'm over complicating the issue but with a new framework hopefully I can find out how others are handling such a scenario.



Apr 29, 2011 at 9:20 AM

I'll try to answer your question at the best of my capabilities... I hope I understand your scenario properly.

You have a large set of homogenous data (or at least a set of clusters of homogenous data), and you want to display them in different views; every view can select a sub-part of the complete set and eventually a subset of the properties.

If I did not misread your post, you already have a cache for the homogenous data your are going to display (PeopleInfoBO), and another one for specific view-models (PeopleInfoViewModel).

As far as I can see you have already dealt with the major issue of your application (i.e. caching data from the DB to avoid to retrieve the same information multiple times), and you already have decided that PeopleInfoViewModels should be cached too (which is a good idea, since you need to share them among views).

Now, regarding how to handle the lists of such view-models, I would answer with a citation from Donald Knuth:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

What I mean is that it is often inefficient to try to optimize something without having a clear understanding of the situation.

Let's say that you use a simple approach, and you create a new PeopleInfoListViewModel every time a new view is displayed. At creation time, you pupulate the Items collection of the view-model by pulling all the proper view-models from the cache. Depending on how the application performs while generating the view for a list, you could decide to keep this implementation or execute your insertions using multiple batch insertions (e.g. on view-model intialization start a DispatcherTimer that pulls a small amount of the required data from the cache and inserts them in the Items collection). Then, you could notice that, since list view-models are hierarchical, you could just re-use them in the upper levels of your hierarchy (e.g. the StateList view-model could contain multiple CityList view-models, instead of a list of PeopleInfoViewModels, and the view could be responsible to 'merge' them).

All in all, I think it is too difficult to design something to be 'optimal' before-hand. I would go with a simple (yet meaningful) approach, test the application to point out the eventaul flaws, and take decisions depending on the test results (what if the caching is too intense and the application keeps requiring too much memory?).

Regarding the refreshing of already existing view-models, it really depends on how you keep the view-models synchronized with the BOs, and if they are unique for each BO (shared among different list view-models). Assuming that you are sharing PeopleInfoViewModels, you could decide to refresh them upon each activation, or (depending on the cost) use an asynchronous timer to refresh them periodically... again, I think that you need to first decide for a simple and effective approach, and then refine it if needed.


I hope this post is meaningful to you...

Apr 29, 2011 at 3:01 PM


Thank you for your time - I am classic for trying to optimize before getting anything done. I should have a stick next to my desk to hit myself with when I start. I'll take your advice and just get something working. If I try to lazy load as much as possible and use a UI control that supports virtualization maybe I'll be surprised.

My primary goal was to check with the community that there was not a CM specific "Don't Do that" approach I should avoid.