title: Business Objects - Containers or functional?
body: <p>Where I work, we've gone back and forth on this subject a number of times and are looking for a sanity check.  Here's the question:  Should Business Objects be data containers (more like DTOs) or should they also contain logic that can perform some functionality on that object.</p>
  
  <p>Example - Take a customer object, it probably contains some common properties (Name, Id, etc), should that customer object also include functions (Save, Calc, etc.)?</p>
  
  <p>One line of reasoning says separate the object from the functionality (single responsibility principal) and put the functionality in a Business Logic layer or object.</p>
  
  <p>The other line of reasoning says, no, if I have a customer object I just want to call Customer.Save and be done with it.  Why do I need to know about how to save a customer if I'm consuming the object?</p>
  
  <p>Our last two projects have had the objects separated from the functionality, but the debate has been raised again on a new project.  Which makes more sense?</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>These results are very similar to our debates.  One vote to one side or another completely changes the direction.  Does anyone else want to add their 2 cents?</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>Eventhough the answer sampling is small, it appears that the majority believe that functionality in a business object is acceptable as long as it is simple but persistence is best placed in a separate class/layer.  We'll give this a try.  Thanks for everyone's input...</p>