¿Por qué no utilizar un contenedor de IoC para resolver dependencias para entidades / objetos comerciales?

Entiendo el concepto detrás de DI, pero estoy aprendiendo lo que pueden hacer los diferentes contenedores de IoC. Parece que la mayoría de las personas abogan por el uso de contenedores IoC para conectar servicios sin estado, pero ¿qué hay de usarlos para objetos con estado como entidades?

Ya sea correcto o incorrecto, normalmente lleno mis entidades de comportamiento, incluso si ese comportamiento requiere una clase externa. Ejemplo:

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);
    }
}

Como puede ver, las dependencias son Constructor Inyectado. Ahora para un par de preguntas.

¿Se considera una mala práctica que sus entidades dependan de clases externas como ShipQuoter? Eliminar estas dependencias parece conducirme a un dominio anémico, si entiendo la definición correctamente.

¿Es una mala práctica usar un contenedor de IoC para resolver estas dependencias y construir una entidad cuando sea necesario? ¿Es posible hacer esto?

Gracias por cualquier idea.

Respuestas a la pregunta(2)

Su respuesta a la pregunta