current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 7 down vote favorite
1

I need help creating view models for the following scenario:

  1. Deep, hierarchical data
  2. Multiple views for the same set of data
  3. Each view is a single, dynamically-changing view, based on the active selection
  4. Depending on the value of a property, display different types of tabs in a tab control

enter image description here

My questions:

Should I create a view-model representation for each view (VM1, VM2, etc)?

1. Yes:
    a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1)
    b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes)

2. No:
    a. Do I use a huge, single view model that caters for all views?

Here's an example of a single view

Figure 1: Multiple views updated based on active room. Notice Tab control

enter image description here

Figure 2: Different active room. Multiple views updated. Tab control items changed based on object's property.

enter image description here

Figure 3: Different selection type. Entire view changes

enter image description here

share|improve this question
    
btw what is a muli view? typo? –  JensG Mar 17 at 15:52
    
"Muli view" was a typo. I meant different views for the same model/view model. My question was, should I remodel/wrap the entire model hierarchy for each view, so each view model only contains what the individual view needs? Or should I create a single view model hierarchy that contains properties from all views? Since I posted this question, I was (un)fortunate enough to find out the pros/cons of the two, the hard way. Will update this thread in the future with a full diagnosis of my experience, once things aren't as hectic. –  jsjslim Mar 18 at 10:20
    
Remember a design rule is to show general things first then go deep into details. it will leave you with a light view and if the user go deeper then new views will appear. so use small views with their viewmodel apart. check this article design user interface –  Csharls Jul 23 at 23:29
    
@jsjslim I shuddered when I read "keep all hierarchies in sync". I suspect you went with the multi-view, and I suspect you regretted it (but I've been wrong before). For the sake of other readers who may have the same question, can you at least give us a quick(ish) answer? –  Guy Schalnat Jul 24 at 2:15
1  
@guy-schalnat The multi-view was a requirement. My problem was trying to figure out how to build the view models. The project is still ongoing, and I can't find the time to write-up a full analysis. But in summary: I should have ignored the model structure, and focused on the views. The complexity that I encountered was self-imposed: I wanted to use WPF's data binding so badly, I got fixated. What I did in the end was good, old "copy/paste/refactor". The final design that emerged was lightweight (little repetition), and more importantly, worked. Will write up a full analysis in the future. –  jsjslim Jul 25 at 0:59

1 Answer 1

up vote 1 down vote

Looking at your mockups, I would definitely recommend creating hierarchy of ViewModels and lots of small Views. And you will most probably have to model quite a bit of the original hierarchy.

To keep things in sync between ViewModels, use either events, or have properties to each other between ViewModels. Sync between Views and ViewModels should be standard notifying properties.

share|improve this answer

protected by gnat Sep 12 at 7:51

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.