title: Prism, Regions, Magic strings and refactoring : am I missing something here?
body: <p>To build a composite application view in my application, with different regions, untill now, I've always used content presenter and used DataBinding to set its content.</p>
  
  <p>If I wanted to change its content, I would just have to use an event aggregator, publish a <em>ViewZoneChangedEvent</em>, subscribe to it in the "shell" window, and update the viewmodel accordingly so that the new data would be available for the binding and the UI be updated.</p>
  
  <p>Now, I recently came across those Regions in Prism, actually I had seen them for a while but I didn't feel comfortable with them, but since Prism is some kind "best practices guidance" maybe I'm missing something : Let me explain why I feel uncomfortable.</p>
  
  <p>with my old way of doing, there is no coupling with the XAML. you never mention any specific magic string that should be present in the XAML, and I think that's essential, since the style can change.</p>
  
  <p>If at least the regions would perform a compile-time check of the region names ( check it really exists somewhere ) that would enforce using valid region names and be very helpful when refactoring, but as far as I know, there's no such thing. Some people use enums and the <code>ToString</code> method of an enum to convert it to a string and use it as a region name, but again, as far as I know, there's no real routine to check if the string typed really is valid and show an error when compiling the way it is done for Brushes.InValidColor for instance.</p>
  
  <p>So, my question is the following : what do the prism regions bring to the table compared to plain old binding (plus eventAggregator if you wish to communicate across ViewModels) ?</p>
  
  <p>and are my assumptions true about the compile-time verification of the region names ?</p>