Question

I guess this is sort of a philosophical question, but I have some code that dynamically adds templated columns to a GridView by generating the XAML at runtime from Model data and loading it using XamlReader. My question is, In an MVVM world, where should I put the code that accomplishes this? At the moment, I have it in the codebehind, but I’m contemplating whether I should move it to the ViewModel.

Answer 1

There is a big movement in WPF/Silverlight developers circles to move to a MVVM architected solution however they dont go futher than simple or general examples.
This isn’t much of an issue in simple applications. It becomes serious when you contemplate

• a screen or page constructed dynamically, perhaps in response to user action
• a composite page consisting of
  regions holding views, perhaps nested
  views, each implemented as MVVP
  triads
• a wizard closing a collection of
  views with a single click

There is significant logic here. Where does it go?

Its exactly this (your question) where I get hangups moving my stuff to MVVM, Ive read a nice article that gave me kind of an ahha moment, this kind of architecture fits into a bigger one where some class is composing the lifecycle of the MVVM trio

If you want to read the full article here Ward Bell gos into greater detail.
It may be that this is just a smaller piece in the bigger picture, another great article discusses the main players in the Composite Application Neighborhood , see here.

What does this all have to do with your problem? Well its my belief that the ViewModel represents the view, and your view is determined at runtime, so if the problem requires that there be dynamically generated columns it may be the responsiblity of something else to create the rendered view and the appropriate viewmodel that fits your final result and instance them.