We have IAppContext which is injected into ViewModel.
This service contains shared data: global filters and other application wide properties.

But there are cases when data is very specific. For example one VM implements Master and the second one - Details of selected tree item. Thus DetailsVm must know about the selected item and its changes.

We can store this information either in IAppContext or inside each concerned VM. In both cases update notifications are sent via Messenger.

I see pros and cons for any of the approaches and can not decide which one is better.

+ explicitly exposed shared properties, easy to follow dependencies
- IAppContext becomes cluttered with very specific data.

the exact opposite of the first and more memory load due to data duplication.

May be someone can offer design alternatives or tell that one of the variants is objectively superior to the other cause I miss something important?

  • 4
    In most cases for me like this, MasterVM contains a property for DetailVM, and DetailVM.CurrentItem gets set when MasterVM.SelectedItem changes. The ViewModels are my application, so it makes sense that they be connected in situations such as a storing TreeView data
    – Rachel
    Dec 3 '12 at 15:22
  • 1
    Like @Rachel, I see a parent-child relationship here between the master VM and its detail VM, and I would architect the two in that way.
    – KeithS
    Jul 10 '13 at 2:07
  • Like @Rachel said, give the children a reference back to their momma. Don't worry about memory, its just a pointer. Jul 8 '14 at 17:12

I hope this answer will benefit others that reach that question, because by timestamp alone I think OP solved the problem long ago. ;-) The post doesn't present immediate solution (I'd need more data from OP for that), but offers some pointers instead.


As mentioned in comments (first by @Rachel), for hierarchical data there's a parent-child relationship.

Uncertainty principle

As with pretty much any design decision, there's the uncertainty principle: hold off with deciding, as long as possible. Implement both and keep them going and see which suits your case better. I should note here I'm not versed AT ALL in WPF, but that sentence:

I see pros and cons for any of the approaches and can not decide which one is better.

strongly indicates laying off decision till you see one approach yields better results than the other will work for you.

It depends

Since there's little information about use cases and amount of shared / specific data, I'll propose some things based on assumptions.

Assuming very different, always case-specific extra data

  1. For each case, create a property file or value objects that can store extra data.
  2. Add mechanism allowing AppContext to pull said property file / value object in by name / id / other.
  3. VMs requiring this should be able to tell AppContext to pull that data when they're initialized. This may even be done via naming convention.

Assuming very different, partially reusable extra data

Proceed as in previous case. Why despite this advice I'm marking this as a separate section? Because in cases of just partial reuse I often find it prudent to just skip reuse at all:

  1. partial reuse tempts, but rarely it really is worth the time spent on thinking "how to reuse it well"
  2. if you botch the reuse, end-result is rarely maintainable
  3. newbies coming to code will be quite confused when they SHOULD reuse and when not and HOW to reuse

Bottom line: clarity suffers. If you aren't sure data will be reused, don't bother.

Assuming great deal of extra data, lots of different cases, significant reuse

Split the app. There's obviously too many apps trying to fit here and patterns you identified may be different domains. At this point I'd took a closer look at DDD patterns (especially Bounded Context) and would consider moving the real shared data from IAppContext to supporting domain.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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