title: Techniques for dealing with anemic domain model
body: <p>I've read some of the questions regarding anemic domain models and separation of concerns.  What are the best techniques for performing/attaching domain logic on anemic domain objects?  At my job, we have a pretty anemic model, and we're currently using "helper" classes to perform the database/business logic on the domain objects.  For example:</p>
  
  <pre><code>public class Customer
  {
      public string Name {get;set;}
      public string Address {get;set;}
  }
  
  public class Product
  {
      public string Name {get;set;}
      public decimal Price {get;set;}
  }
  
  public class StoreHelper
  {
      public void PurchaseProduct(Customer c, Product p)
      {
           // Lookup Customer and Product in db
           // Create records for purchase
           // etc.
      }
  }
  </code></pre>
  
  <p>When the app needs to do a purchase, it would create the StoreHelper, and call the method on the domain objects.  To me, it would make sense for the Customer/Product to know how to save itself to a repository, but you probably wouldn't want Save() methods on the domain objects.  It would also make sense for a method like Customer.Purchase(Product), but that is putting domain logic on the entity.</p>
  
  <p>Here are some techniques I've come across, not sure which are good/bad:</p>
  
  <ol>
  <li>Customer and Product inherit from an "Entity" class, which provides the basic CRUD operations in a generic fashion (using an ORM maybe).
  
  <ul>
  <li>Pros: Each data object would automatically get the CRUD operations, but are then tied to the database/ORM</li>
  <li>Cons: This does not solve the problem of business operations on the objects, and also ties all domain objects to a base Entity that might not be appropriate</li>
  </ul></li>
  <li>Use helper classes to handle the CRUD operations and business logic
  
  <ul>
  <li>Does it make sense to have DAOs for the "pure database" operations, and separate business helpers for the more business-specific operations?</li>
  <li>Is it better to use non-static or static helper classes for this?</li>
  <li>Pros: domain objects are not tied to any database/business logic (completely anemic)</li>
  <li>Cons: not very OO, not very natural to use helpers in application code (looks like C code)</li>
  </ul></li>
  <li>Use the Double Dispatch technique where the entity has methods to save to an arbitrary repository
  
  <ul>
  <li>Pros: better separation of concerns</li>
  <li>Cons: entities have some extra logic attached (although it's decoupled)</li>
  </ul></li>
  <li>In C# 3.0, you could use extension methods to attach the CRUD/business methods to a domain object without touching it
  
  <ul>
  <li>Is this a valid approach?  What are pros/cons?</li>
  </ul></li>
  <li>Other techniques?</li>
  </ol>
  
  <p>What are the best techniques for handling this?  I'm pretty new to DDD (I'm reading the Evans book - so maybe that will open my eyes)</p>