title: What is the difference between a business object and business logic
body: <p>I'm trying to structure my WPF MVVM application according to best practises. I have to start with a lot of existing code so don't have the option of resolving all structural flaws straight away. I like the following solution structure.</p>
  
  <p><a href="http://www.paulspatterson.com/technology/dot-net-development/mvvm-and-wpf-for-vb-net-series-2-part-1-again/" rel="nofollow noreferrer">http://www.paulspatterson.com/technology/dot-net-development/mvvm-and-wpf-for-vb-net-series-2-part-1-again/</a></p>
  
  <p>This separates the solution into the following projects; BusinessLogic, BusinessObjects, Infrastructure (Common reusable utilities), WPF Shell and Modules (application components to be injected using an IOC container).</p>
  
  <p>I understand that the business object represents the human world entity whereas the business logic is the implementation details as discussed in this question.</p>
  
  <p><a href="https://stackoverflow.com/questions/3273800/what-are-business-objects-and-what-is-business-logic">What are Business Objects and what is Business Logic?</a></p>
  
  <p>Therefore using MVVM does the business object just become a dumb container that doesn't actually do anything other than wait to have its properties changed by external business logic? I don't see how you decouple the business object from the business logic to the point of being able to have them in separate assemblies. </p>
  
  <p>Take the following hugely simplified code:</p>
  
  <pre><code>public class Chart
  {
  
      private SizeChart _activeChartSize = new SizeChart();
  
      public void Draw() {
          //  Size the chart object
          _activeChartSize.Size(this);
          //  Do other draw related things
      }
  
  }
  
  public class SizeChart
  {
  
      public void Size(Chart chartToSize) {
          //  Manipulate the chart object size
      }
  
  }
  </code></pre>
  
  <p>In the context of the MVVM solution structure described above (to my mind at least) the SizeChart class would be business logic and the Chart class would be a business object but placing them in different projects would be a circular dependency. Is the SizeChart class business logic or a business object and where in the solution structure should the SizeChart class reside if I adopt this proposed MVVM solution structure?</p>
  
  <p>Apologies if this is an incredibly obvious and simple question to some people but it's difficult when you can't start with a clean slate to know how to best start transitioning poorly structured code to well structured code. </p>