Best practice for storing shared data?

Topics: Prism v1, Prism v2 - WPF 3.5
Jan 21, 2009 at 6:45 AM
Hi all,

how do you hold your shared data over different within your WPF/CAL project? In other words: how to share parts of the model?

Actually I have to store about 5 different lists I need in different modules. Source is a RDBMS. These lists serves as reference data for comparisons and rarelay must be updated via the UI.
I tend to implement this lists separate as class thats inherits from List<TYPE> (modelclass). For every class I create a datalayer service for querying, inserts, updates etc.
Both modelclass and datalayer class are registered within Unity. To simplifying explaination I ignore here use of interfaces implemented by the classes.

So I'm not sure if this is the best way. It seems to me its actually the fastest and simpliest way.

- seems to be simple

- registers model within Unity (not only services)
- if more shared data are needed the more several classes are being registered within Unity

Creating one 'SharedDataService' holds fields with references to the several lists (maybe a wrapper for Dictionary<TKey, TValue) or hardcoded fields of appropriate type).
If choosen the dictionary version the several lists must implement a custom Interface.

CAB uses the State. But I dont like the untyped object way...

How do you share your data within a WPF/ CAL project?

Thanks für suggestions.
Jul 10, 2009 at 6:20 AM

I'm curious what you did, I'm wondering the same thing.


Jul 27, 2009 at 7:49 AM

I used the solution I've evaluated by myself and decribed above. It works fine for me; I guess at this point should everybody do whats ok for him/her. If you want to share data between views you can also look into Prisms docu under Technical Concepts > Communication > Region Context.

bye, schue

Jul 29, 2009 at 1:05 PM

[schue] How do you share your data within a WPF/ CAL project?

The TopDownUIComposition solution in PRISMV2 Drop 7 shows an excellent example of how this can be done
QuickStarts\Visual Composition\TopDown\

This demo uses a combination of the Model-View-Presenter (MVP) pattern and the Model-View-ViewModel (MVVM) pattern, aka Presentation Model and Application Model.    By having multiple views share the same model (see Martin Fowlers Presentation Model) you effectively share the same data without having to have a lot of complex logic to maintain state.   Each view can update the model and the other views will be notified via the observer pattern (INotifyPropertyChanged).

Trying to use MVVM alone has introduced the limitations that Martin Fowler discussed in THIS ARTICLE (paragraph above Figure 11).   As he suggest, it was the limitations that introduced the need for MVP.   Combining them gives us the best of both worlds.  


Aug 4, 2009 at 11:25 AM

I agree that in most situations ViewModels alone are not sufficent and you need something on top to coordinate them. Ward Bell discusses similar concept on his blog and calls it a "Screen Factory". . Note that in his term Screen refers to some portion of your UI that handles a specific task - but it can consist of multiple views collaborating to implement one task. On the other hand you would also have multiple screens in one application and thus multiple "Screen Factories".

However if you are looking for very loose coupling between ViewModels you can still implement a message bus (using a Mediator pattern) to synchronize their state changes. In Prism this would be the EventAggregator but you can also looks at the Messanger class created by Marlon Grech and Josh Smith: (also part of their MVVM Foundation project

Aug 4, 2009 at 2:34 PM

Thank you kobush, that was excellent reading!   Early in my architecture days I lost faith in blogs because I found so many people teaching, when they didn't understand the concepts, perfect case in point were the countless blogs stating that the difference between MVC and MVP is that in MVP the View does not communciate with the model; a partial truth (Passive MVP) which was more the exception than the rule because any data-binding resulted in MVP being supervising controller.   In time, because I didn't know enough to discern the truth,  I isolated my readings to authoritative sources such as the Microsoft P&P folks, Fowler (for architecture) and Papa for data.

Although it would have been nice if Ward had provided examples (spoiled by fowler who provides source and UML although I doubt we'll find Agile folks using UML now-a-days) I found his blog(s) to be a breath of fresh air; I particularly enjoyed  which suggested to me that he does his homework and qualifies as an authoritative source.  A source that recognizes that, like technologies, architectural patterns have to continually grow/change with the times and he has taken on that challenge.

As for the Grech and Josh Smith - I could be wrong but I think they are attempting to solve problems that are already solved with the PRISM framework but it is to early to tell and I'll bookmark this one.   The deeper I dig into the PRISM framework (work in progress) the more impressed with it I become as I see the team is solving many problems for us. 


Aug 4, 2009 at 5:09 PM

Ward started very interesting (and important) discussion that now continues among WPF Disciples. You should also read some thoughts from Glenn Block ( and David Hill (

While Prism provides good foundation for building composite (aka modular) application it doesn't deal directly with the MVVM patterns. This is why we start to see a growing number of MVVM frameworks that try to fill the gap (not only from Josh and Marlon but also from Karl Shifflett, Sacha Barber, and Bill Kempf). In particular I agree with David Hill's point that we need more support in tooling for creation and binding to ViewModels. For example it would be cool if we could specify bindings to ViewModels in Blend and get the InteliSense like experience. Or even ability to provide design-time sample data in form of mock ViewModels (one example here Also the creation of the MVVM triad is not an easy topic (both View-first and ViewModel-first approaches are valid depending on the situation). 

I hope that eventually this becomes part of the framework (and get support in tools) but we should look closer at this in the next version of Prism too.