title: Why not use an IoC container to resolve dependencies for entities/business objects?
body: <p>I understand the concept behind DI, but I'm just learning what different IoC containers can do.  It seems that most people advocate using IoC containers to wire up stateless services, but what about using them for stateful objects like entities?</p>
  
  <p>Whether it's right or wrong, I normally stuff my entities with behavior, even if that behavior requires an outside class.  Example:</p>
  
  <pre><code>public class Order : IOrder
  {
  
      private string _ShipAddress;
      private IShipQuoter _ShipQuoter;
  
      public Order(IOrderData OrderData, IShipQuoter ShipQuoter)
      {
          // OrderData comes from a repository and has the data needed 
          // to construct order
          _ShipAddress = OrderData.ShipAddress;  // etc.
          _ShipQuoter = ShipQuoter;
  
      }
  
      private decimal GetShippingRate()
      {
          return _ShipQuoter.GetRate(this);
      }
  }
  </code></pre>
  
  <p>As you can see, the dependencies are Constructor Injected. Now for a couple of questions.</p>
  
  <ol>
  <li><p>Is it considered bad practice to have your entities depend on outside classes such as the ShipQuoter?  Eliminating these dependencies seems to lead me towards an anemic domain, if I understand the definition correctly.</p></li>
  <li><p>Is it bad practice to use an IoC container to resolve these dependencies and construct an entity when needed?  Is it possible to do this?</p></li>
  </ol>
  
  <p>Thanks for any insight.</p>