title: MVVM: ViewModel and Business Logic Connection
body: <p>After doing a few Projects using the MVVM Pattern, Im still struggling with the Role of the ViewModel:</p>
  
  <p>What I did in the past:
  Using the Model only as a Data Container.
  Putting the Logic to manipulate the Data in the ViewModel. (Thats the Business Logic right?)
  Con: Logic is not reusable.</p>
  
  <p>What I'm trying now:
  Keeping the ViewModel as thin as possible.
  Moving all Logic into the Model Layer.
  Only keeping presentation Logic in the ViewModel.
  Con: Makes UI Notification realy painful If Data is Changed inside the Model Layer.</p>
  
  <p>So I will  give you an Example to make it more clearer:</p>
  
  <p>Scenario:
  Tool to Rename Files. 
  Classes:
  File : Representing each File;
  Rule: Contains Logic how to Rename a File;</p>
  
  <p>If Im following approach 1:
  Creating a ViewModel for File, Rule and the View -> RenamerViewModel.
  Putting all Logic in the RenamerViewModel: 
  Containing a List of FileViewModel and RuleViewModel and the proceeding Logic.
  Easy and fast, but not reusable.</p>
  
  <p>If Im following approach 2:
  Creating a new Model Class -> Renamer, which contains a List of File, Rule und the proceeding Logic to interate over each File and apply each Rule.
  Creating a Viewmodel for File, Rule and Renamer.
  Now the RenamerViewModel only contains an instance of Renamer Model, plus two ObservableCollections to wrap the File und Rule List of the Renamer.
  But the whole Logic is in the Renamer Model. So if the Renamer Model is triggered to manipulate some Data by Method Calls, the ViewModel has no Clue which Data is manipulated.
  Because the Model doesnt Contain any PropertyChange Notification and I will avoid that.
  So the Business and Presentation Logic is seperated, but this makes it hard to notify the UI.</p>