.net MVVM application and design-time data

Question

5.00/5 (1 vote)

See more:

.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.

HTML

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 9:26am

koleraba

Add a Solution

2 solutions

Add a Solution

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

_Maxxx_ · Accepted Answer · 2013-05-08T17:43:00

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!

Posted 8-May-13 17:43pm

_Maxxx_

Comments

koleraba 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_ 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

Mohammed Hameed · Accepted Answer · 2013-05-08T23:44:00

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!!!

Posted 8-May-13 23:44pm

Mohammed Hameed

Comments

koleraba 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 9-May-13 11:31am

Okay, let me discuss this with my colleague and will get back to you.

.net MVVM application and design-time data

2 solutions

Solution 1

Solution 2

Add your solution here

Preview 0

.net MVVM application and design-time data

2 solutions

Solution 1

Solution 2

Add your solution here

Preview 0

Existing Members

...or Join us