title: Split view into two separate views
body: <p>I'm building a WPF application which very simplified looks something like this:</p>
  
  <p><img src="https://i.stack.imgur.com/4JNlo.png" alt="My WPF application"></p>
  
  <p>I have an ApplicationView which holds the menu and a ContentControl.
  The ContentControl binds to the property CurrentViewModel which is set by the menu and rendered by its related View (Views and ViewModels are coupled by DataTemplates defined in the App.xaml).</p>
  
  <p>I found this approach on <a href="http://rachel53461.wordpress.com/2011/12/18/navigation-with-mvvm-2/" rel="nofollow noreferrer">Rachel Lim's blog</a></p>
  
  <p>So in this example my View contains a list of duties as well as a "Details" window of the currently selected duty.</p>
  
  <p>This setup works fine, but I think my ViewModels are getting too fat!
  The non-simplified version of this ViewModel is up at around 500 lines of code, for handling:</p>
  
  <ul>
  <li>Initializing filters</li>
  <li>Logic for filtering list</li>
  <li>Displaying duty details</li>
  <li>Add/Update/Cancel/Delete logic</li>
  </ul>
  
  <p>Now I'm very new to WPF but that seems like too much code, yea?
  And it will be even bigger before I'm finished with it.</p>
  
  <p>Anyways, I was thinking that I could split the ViewModel into two separate ViewModels; one for holding list and filters and one for showing the details. But how is this best accomplished?</p>
  
  <p>I have thought of two approaches, but don't know which is preferable:</p>
  
  <ol>
  <li><p>Create a DutyMasterView whose sole purpose is to hold two ContentControls for the actual Views (ie DutyListView and DutyDetailView each with their own ViewModel)?
  I'm using MVVM Light as my framework so I suppose I could use the messaging service to tell the DutyDetailViewModel which Duty to display, right?
  Alternately create a DutyMasterViewModel which exposes the selected duty.</p></li>
  <li><p>Ditch the DutyMasterView and nest the DutyDetailView in the DutyListView.</p></li>
  </ol>
  
  <p>Does it make sense to split my ViewModel into two or should I just stick with my fat ViewModel?
  If splitting the ViewModel is recommended which of my suggestions makes most sense?
  Are there other approaches that I should consider?</p>