0

I used the solution provided in this answer in order to use two different view models dependent on the type within my composite collection.

An extract of the view is as follows:

<ItemsControl ItemsSource="{Binding DecksAndCards}" >
    <ItemsControl.Resources>
        <DataTemplate DataType="{x:Type viewModel:DeckViewModel}">
            <view:DeckView />
        </DataTemplate>
        <DataTemplate DataType="{x:Type viewModel:CardViewModel}">
            <view:CardView />
        </DataTemplate>
    </ItemsControl.Resources>

...

The view resides within a View project referencing only the ViewModel project until now.

However by using x:Type (which I think acts as a static reference) I need to add to my view project a reference to my DomainLayer project, because the ViewModel project also references it.

If I don't add this reference I get the error: Unknown build error, 'Cannot resolve dependency to assembly 'DomainLayer, [...] because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.

Following the MVVM pattern the View should not have references to the Model directly. So my question is, is there another solution than the one I posted above or do I need to break the pattern in this case?

Community
  • 1
  • 1
user2653422
  • 1,095
  • 1
  • 12
  • 18
  • 1
    The problem isn't related to the multiple data templates; that's excellent practice in MVVM theological terms, and it's neutral as far as project references are concerned. Are you planning to reuse the view project with an unrelated set of viewmodels that don't have the same model project? Is there a concrete problem introduced by adding the model project reference, or are you just worried about "breaking the rules"? There are some sacred MVVM rules, like not giving a viewmodel a reference to a control. Others may be matters of form. This is the latter. – 15ee8f99-57ff-4f92-890c-b56153 May 05 '17 at 13:28
  • @EdPlunkett I'm just curious if there is another solution to the one I used. The reference will cause no problem as I will not reuse the view project. – user2653422 May 05 '17 at 13:33
  • "the View should not have references to the Model directly". That is unavoidable if the view model publicly uses declarations from the model. A view model class may for example be derived from a model class. Or declare a property with a type that is declared in the model. – Clemens May 05 '17 at 13:38
  • @Clemens When I only need one ViewModel and use it like this ` [...]` I don't need a reference to the Model from my View project. This difference was the reason for my question. – user2653422 May 05 '17 at 13:47
  • Googling the error you got, it looks one possible cause [might be that your viewmodels inherit from your models](http://stackoverflow.com/a/22961891/424129). If that's the case, I wouldn't do that. I derive viewmodels from a `ViewModelBase` and the model classes (if any) are either private, or are exposed via properties. This error isn't *why* I wouldn't do that -- but I wouldn't do that. – 15ee8f99-57ff-4f92-890c-b56153 May 05 '17 at 13:49
  • You could [write a DataTemplateSelector](https://msdn.microsoft.com/en-us/library/system.windows.controls.datatemplateselector.selecttemplate(v=vs.110).aspx) to avoid the problem with implicit templates here, but... meh. I'd add the reference and get on with my life. – 15ee8f99-57ff-4f92-890c-b56153 May 05 '17 at 13:52
  • @EdPlunkett My ViewModels also inherit from a ViewModelBase. Data from the Model is exposed by properties in the viewmodels. So this is standard MVVM. Thank you for the DataTemplateSelector hint. Could be useful if the view project is ever used for sth. different. – user2653422 May 05 '17 at 13:59
  • In any case the solution to that other case was to reference the offending assembly. DataTemplateSelectors aren't my first choice as a solution to anything, it's just an option to be aware of. – 15ee8f99-57ff-4f92-890c-b56153 May 05 '17 at 14:05

0 Answers0