Silverlight PRISM, instantiate a view and pass data into the viewmodel

Topics: Prism v2 - Silverlight 3
Sep 25, 2009 at 11:24 AM


I have been looking around and haven't found much information on this yet. I have a PRISM project set up and it all seems to be working so far, within the main class of a module I am programatically creating my views.

What I am trying to do is get an object sent through to the viewmodel for each instance of the view. At the moment I am trying to pass the object into the views constructor and do something like this:

   public MyView(IUnityContainer container, List<string> myDataObject)

MyViewViewModel vm = LayoutRoot.DataContext as MyViewViewModel;
.DataObject = myDataObject;

This causes a NullReferenceObject for vm.DataObject, I assume the viewmodel hasn't been properly instantiated at this point.

I have been told about using the container to register an instance but I don't see how this would work if I had say 5 view instances and 5 data objects of the same type to pass to the views, how would the view know which data object belonged to it? (even if it was named). Even then, how does that correct data object make it to the view model? I need the view model for each view instance to have the correct data object available for data binding.

Can anyone guide me on how this should be done? should the data object even be send via the view?

Thanks for your time

Sep 27, 2009 at 3:33 AM
Edited Sep 27, 2009 at 3:36 AM

I would say download the source I posted here which is working great for a commercial software product, so I have no choice but to do this correctly ot I am out of business.





Here is a visual:



1) I am fairly sure the above code is specifically failing due to Unity having this type registered?? No matter as you almost certainly DO NOT want this path.

2) Remember you XAML rules, remember what you get for free in paying one small price (just like NHibernate actually and for the same reason) - empty constructors are required for any work declared as XAML. Unity indeed does resolve the view in the way I will describe below but it is still all XAML. You only ask for your viewmodel from the container, and preferrably it gets injected into a coordinating presenter (but I typically do this only where I have complex cross module coordination requirements and that coordination is specific to one module) - say a module with master-detail and itself hosting 4-5 views, I try to keep a 1-1 ration when possible for views and all the extra backing assets and a XAP that is never referenced directly,  but loaded via the module catalog (I have an  RIA service for all the Unity/Prism  bits as simple implementations of their exposed extension contracts). (of course this is expensive at the price of better loose coupling at a finer degree).


(YOU CAN SKIP ALL THIS AND LOOK AT CODE HERE ON CODE PLEX - just find the Prism project under my name)

XAML 'stuff' that you want to decalre in XAML (and I doubt you want to say 'I will never need this view in any other form such as: <MyView x:Name="MainView" />

This is almost always a good sign the the design has taken a bad path because as programmer, using the power of XAML for views, and an IoC for your other dependencies, you are sabatoging the value. Typically this works if say you have a Collection of actuaql Views (NOT a view model) and you are binding that to  an outer itemscontrol, where iit has a datatemplate with a contentprenter somewhere with its 'Content' property set to the item in your 'ViewCollection'.

I just am now realizing this is not that hard but I suggest you review the project as I said above and feel free to ask any questions you come up with.

One item I do : On module load, register first your View, then the ViewModule (you will see why in a sec)

Unity will resolve the ViewModel for me, and I place an instance of the always empty coostructor view in the paramater list of the ViewModel


A viewmodel for me almost always has a property called View for it's public face

If you cannot have a design assist on a view (if it has a constructor for example) it will work but who cares if your doing so much more effort for so much less benefit?


So I say:


Var viewM = Container.Resolve<IViewModel>("customerListVM");



This is not my idea, it is in the sample apps for Prism. Just remember you should not be coding anything in most cases except where the view fires a command you handle in the view model. Always let the runtime for WPF or silverlight spin up the view because the visual tree is a picky animal. You cannot replicate some advanced XAML techniques anyway in code (nested visual tree adorners in one think,,, you can do it but it's a bitch).


I hate all these devs saying the m'X' pattern is so cool (you know the one) when they cannot even spell the work 'Aggregation';. This is no fad it is the best solution to many core problems  that are often humjan in nature, like the designer/dev workflow.


I could go on but anything I could say you ger much much more in the code.







Sep 27, 2009 at 6:41 PM

Hi Damon,

Thanks for the reply, I went with the approach of just manually creating the view and view model and passing the viewmodel to the view then adding the view to the region from within the main module class.


Thanks again