title: Are WPF related properties inside a ViewModel a violation of MVVM best practices?
body: <p>Here is an example case to elaborate:</p>
  
  <p>I am dynamically creating a simple Bar Graph using an ItemsControl in my View and binding the items to a collection of BarViewModels (each containing percentage a value) in my BarGraphViewModel.
  Each bar should have a different color. The colors should be chosen from a collection e.g. <code>{Color1, Color2, ..}</code></p>
  
  <p>The collection itself is constant but the number of bars will depend on the circumstances.</p>
  
  <p>A simple solution would be to create a simple BarViewModel like so:</p>
  
  <pre><code>public class BarViewModel
  {
      public int Percentage { get; set; }
  
      public SolidColorBrush Stroke { get; private set; }
  
      public BarGraphViewModel(SolidColorBrush stroke)
      {
          Stroke = stroke;
      }
  }
  </code></pre>
  
  <p>(I left out property changed and validation implementation for brevity)</p>
  
  <p>Now I could just create a BarViewModels from my BarGraphViewModel for each percentage and pass in the appropriate ColorBrush created from my Color collection.</p>
  
  <p>Then in Xaml I would create a simple ItemsTemplate that will bind to these properties.</p>
  
  <p>Only now, since it contains a property of type SolidColorBrush, my ViewModel depends on the Presentation framework and should I want to use it in another environment it will have to be changed.</p>
  
  <p>Does this therefore break MVVM best practices, or is it acceptable (you gotta draw the line somewhere or things get too complicated)</p>
  
  <p>I just wanted to see what other people think about this and if there are other solutions that keep the ViewModel totally ignorant of the Presentation Layer without getting too complicated. 
  I could imagine that ValueConverters could help?</p>