Question about Container.Resolve

Topics: Prism v4 - Silverlight 4
Jun 28, 2012 at 10:39 PM
Edited Jun 29, 2012 at 6:17 AM

In UICompositionQuickStart all Views receive it's corresponding ViewModel as a parameter:

        public EmployeeSummaryView(EmployeeSummaryViewModel viewModel) {
            this.InitializeComponent();

            // Set the ViewModel as this View's data context.
            this.DataContext = viewModel;
        }

I suppose that it will help resolve things better when in the MainRegionController it does:

view = this.container.Resolve<EmployeeSummaryView>();

My question is:

I won't use the ViewModel as a DataContext but as a StaticResource for the view instead (I won't set the DataContext but will use the ViewModel as a StaticResource in the view's xaml), then, given that the view won't have the ViewModel parameter, will "container.Resolve<EmployeeSummaryView>();" resolve all necessary types, including the EmployeeSummaryViewModel that will be in the xaml only?

 

Developer
Jun 29, 2012 at 2:40 PM

Hi,

Based on my understanding creating objects defined in XAML by partnering with an Inverse of Control Container is currently not supported. Hence, the container will only resolve the dependencies you have defined for your registered class by using the property-based or constructor-based injection approaches, according to the specific container you used.

As you may find, there are several ways the view and the view model can be constructed and associated at run time, and not all include using a dependency injection container, for example you could check the approach used in the QuestionnaireView.xaml in the MVVM Quickstart, in which the view model is declaratively instantiated in Xaml. In this case when the view is constructed, the corresponding view model object will also be constructed, although this may only be possible if your view model does not have any constructor arguments due to the aforementioned limitations.

I hope you find this useful,

Agustin Adami
http://blogs.southworks.net/aadami

Jun 29, 2012 at 10:18 PM
Edited Jun 30, 2012 at 7:23 PM

The QuestionnaireView.xaml declares the datacontext in xaml, but what if I don't use the DataContext at all, and have the ViewModel as a StaticResource instead , as in:

    <UserControl.Resources>
        <ViewModels:CustomersViewModel
            x:Key="CustomersViewModel" />
    </UserControl.Resources> 

...

<sdk:DataGridTemplateColumn Header="City" >
    <sdk:DataGridTemplateColumn.CellTemplate >
        <DataTemplate>
            <ComboBox ItemsSource="{Binding Cities, Source={StaticResource 
                                                         CustomersViewModel}}" 
                        SelectedItem="{Binding City, Mode=TwoWay}" 
                        DisplayMemberPath="CityName"
                        SelectedValuePath="CityID"
                    />
        </DataTemplate>
    </sdk:DataGridTemplateColumn.CellTemplate>
</sdk:DataGridTemplateColumn>

I ask you this because I discovered that when working with certain controls, just as the DataForm, or cases like the one I depicted above, a ComboBox inside a DataGrid or DataForm, there were some cases that it worked best when I had the ViewModel used as a StaticResource instead of with the DataContext, I don't know why, but I simply plan to develop those views using the static resource approach, and I don't want to have problems when I do it using Prism modulaity.

Then, do you think it'll work that way?

Rafael Soteldo

 

P.S.: My ViewModels are parameterless


Developer
Jul 2, 2012 at 6:13 PM

Hi Rafael,

Based on my understanding you should be able to use this approach without problems. As far as I know, mainly the disadvantages, will be that your view will have to know its corresponding view model type, which might not be promoting loosely coupling between these components. Also, as you mentioned the view model constructor will have to be parameter-less and you may not be benefiting from the use of dependency injection containers to resolve this instances. Although, you should be able to retrieve registered components from the container by using the ServiceLocator, as an alternative.

Another point to consider, could be that every time you create a new view this way, a new instance of the corresponding view model will be created, not allowing the use of singleton instances.

Regards,

Agustin Adami
http://blogs.southworks.net/aadami

Jul 2, 2012 at 6:25 PM

Thank you Agustin for answering.