Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: WPF Design MVVM .NET4.5
Hi
 
I have a more theoretical than a "hands on" question regarding the "design-time" data for WPF applicatons which use the MVVM pattern.
 
Lately I use two kinds of view-models in my applications. The "runtime" view-models which are used at runtime and "design-time" view-models which are used at design-time(when the designer is designing the views in expression blend). Everything I read about this topic suggests that the design-time view-models should be located in a different assembly so you don't have to ship them with the application. And therein lies my problem. Let's say I have two assemblies: Assembly XYZ.ViewModel(containing the runtime view-models) and XYZ.Design(containing the design-time view models). Since I oftenly use IOC containers both the design-time and runtime view-model for the same view must implement some shared interface. So in which assembly should I put the interfaces? If I put them in the XYZ.Design assembly than the XYZ.ViewModel must reference that assembly and I have to ship it with the appliation. I tried to put the interfaces in the XYZ.ViewModel assembly but that would create circual dependency becouse the XYZ.ViewModel assembly must reference the XYZ.Design assembly for the design-time view-models and the XYZ.Design assembly has to reference the XYZ.ViewModel assembly becouse of the interfaces.
 
The only solution to this problem seems to be to create the third assembly XYZ.Interfaces and put all the interfaces in that assembly. This approach works If I use the IoC container to assign the design-time view-model to the view or if I use the following expression in the view.
d:DataContext{d:DesignInstance, Type=design:SomeType, IsDesignTimeCreateble=True}
 
But it seems to me that creating a separate assembly just to contain the view-model interfaces is to much. If you have multiple aseemblies containing view-models(let's say for different applicaton moduls) than you end up with three assemblies for each one.
So my question is: Has anybody found a better or different approach to deal with this problem? Any thoughts on the subject will be appreciated.
 
Uroš
Posted 8-May-13 10:26am
koleraba1.2K
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

Interesting question.
 
I'm not a big IOC user so what I offer may not be applicable.
 
in my mvvm 'framework' my design time data (essentially view models) inherit from the run time view models.
 
I initially put them in the view project with the views - but I just had a quick try and moved the design time view models into their own project with their own namespace, changed the references in the views and bob was, as they say, my uncle.
 
I'd guess that using IOC this would be possible too assuming you can refer to a concrete class (the real VM) when you are dealing with the design time vm?
 
My articles are here[^]
in case you want to have look to see what I'm talking about!
  Permalink  
Comments
koleraba at 9-May-13 10:35am
   
Thank you for your answer. Maybe one more question. Did you move just the design-time models or all of them. Becouse if you moved just the design view-models than, I guess, that would again create a circualar dependency, since the views need the design view-model and design view models need the run-time view-models which thay extend. PS. Do you know how people say you learn something new every day? Well today I learned a new english phrase :). I actually had to google the "bob is my uncle". Uroš
_Maxxx_ at 9-May-13 18:39pm
   
Hope you will use "Bob's your uncle" in a conversation today! (Lucky I din't say "Robert's your father's brother - which is quite common as Bob's your uncle is so ubiquitous)
My ViewModels are in their own project, separate from the Views (which struck me as being the best way as it ensures separation - the views have a reference to the ViewModel project but not vice versa)
Originally my design time view models were in the view project - so moving them to their own project too seems to work quite well.
With my 'framework' I actually separate my ViewModels from ViewData (essentially the ViewModel has the functionality, and the viewmodel contains a viewdata object which is purely the data.
I'm not suggesting that's how you should go - but moving the viewModels into their own project is a sensible move I think
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

Hi,,,
I support your last solution only because I think thats the most effective one in your scenario.
 
I suggests you to give it a name something like XYZ.Common (instead of XYZ.Interfaces). By this I mean dont tie it only for defining Interfaces but also other types as well which are meant to be commonly used/shared by both ViewModels (Design & Runtime).
 

Do let me know if you want any further clarifications on this.
 
Best of LUCK!!!
  Permalink  
Comments
koleraba at 9-May-13 10:43am
   
Thank you for your answer Mohammed. I used the name XYZ.Interfaces just to illustrate a point. The name I actually choose is XYZ.ModuleName.View.Common. But since the design-time view-models are very simple, the above mentioned project contains just the interfaces and a few view-models which do not need their design-time equivalent. Uroš
Mohammed Hameed at 9-May-13 11:31am
   
Okay, let me discuss this with my colleague and will get back to you.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 587
1 Sergey Alexandrovich Kryukov 479
2 Maciej Los 305
3 Mathew Soji 195
4 Richard MacCutchan 145
0 OriginalGriff 7,356
1 Sergey Alexandrovich Kryukov 6,712
2 DamithSL 5,461
3 Manas Bhardwaj 4,916
4 Maciej Los 4,475


Advertise | Privacy | Mobile
Web04 | 2.8.1411023.1 | Last Updated 9 May 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100